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ABSTRACT 


This  study  outlines  the  concepts  and  general  specifications  for  an 
Automated  Combat  Engineer  Operations  and  Planning  System  (ACEOPS).  ACEOPS  is 
compatible  with  the  Army  Command  and  Control  Master  Plan  and  consistent  with 
the  Command  and  Control  Subordinate  System  architecture.  ESC  determined  that 
(1)  it  is  feasible  to  automate  essential  engineer  planning  and  operational 
activities,  and  (2)  a  system  can  be  developed  for  use  during  both  peacetime 
and  wartime.  Although  the  study  focuses  mainly  on  the  automation  needs  of 
combat  engineers  in  Europe,  the  automation  concept  could  be  applied  throughout 
the  Army.  The  relationship  of  the  combat  engineer  system  to  other  battlefield 
systems  is  discussed.  Constraints  on  engineer  system  development  imposed  by 
total  force  automation  plans  and  developments  are  identified  and  assessed. 
General  functional  requirements  specifications  are  described  for  use  as 
initial  user  requirements  and  to  help  structure  early  software  development. 
The  study  also  recommends  actions  which  should  be  taken  to  ensure  that 
engineer  needs  are  considered  in  a  timely  and  adequate  manner  in  battlefield 
automation  activities  already  under  way. 
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AUTOMATED  COMBAT  ENGINEER  OPERATIONS 


AND  PLANNING  SYSTEM  (ACEOPS) 

I.  INTRODUCTION 

1.  Purpose.  This  paper  outlines  the  concepts  supporting  and  gives  the 
general  specifications  for  an  Automated  Combat  Engineer  Operations  and 
Planning  System  (ACEOPS).  ACEOPS  will: 

a.  Improve  the  planning  methods  and  command  and  control  structure 
used  by  combat  engineers  in  the  forward  combat  zone  (FCZ). 

b.  Assure  timely  provision  of  the  combat  engineer  input  and  support 
essential  to  tactical  decisions  and  operations. 

2.  Scope.  The  ACEOPS  concept  development  was  constrained  by  the 

approved  Army  tactical  (corps  and  below)  command  and  control  structure  and 
architecture:  special  emphasis  was  given  to  the  countermobility  operations 

task.  A  fairly  detailed  draft  functional  requirements  specification  document 
was  prepared  for  standard  information  transfer  and  reporting  needs.  Hardware 
and  software  capability  requirements  were  identified,  but  specific  brands, 
models,  configurations,  or  developers  were  not  evaluated  or  recommended. 

3.  Background. 

a.  In  1974,  the  US  Army,  Europe  (USAREUR)  Automated  Barrier  Planning 
System  (ABPS)  began  operating  at  V  and  VII  Corps  data  processing  installations 
(DPIs).  The  ABPS,  a  static  bookkeeping  system,  was  designed  to  expedite  the 
peacetime  countermobility  (barrier)  planning  process  by  automating  the  labori¬ 
ous  data  tabulation  and  report  preparation  processes.  The  ABPS  has  been  mar¬ 
ginally  successful,  but  because  of  its  system  and  operating  environment 
requirements,  does  not  and  cannot  meet  current  count ermobility  planning  needs 


within  USAREUR.  Accordingly,  in  January  1983,  the  USAREUR  Deputy  Chief  of 
Staff  for  Engineering  (DCSENGR)  asked  the  US  Array  Engineer  Studies  Center 
(ESC),  to  help  determine  the  specifications  for  and  feasibility  of  creating  a 
dynamic  Countermobility  Operations  Planning  System  (COPS).  COPS  would  be 
designed  both  for  peacetime  planning  and  for  controlling  wartime  obstacle  plan 
execution. 

b.  The  Deputy  Commander,  US  Array  Corps  of  Engineers  (USACE), 
approved  the  USAREUR  DCSENGR* s  request,  and  tasked  ESC  to  begin  the  project  in 
February  1983.  While  conducting  background  research  for  the  study  plan,  ESC's 
study  team  discovered  that  the  COPS  concept  was  an  integral  part  of  a  larger. 
Army-wide  issue  that  needed  to  be  considered  if  the  USAREUR  DCSENGR* s  needs 
were  to  be  met.  This  larger  issue  involves  tactical  command,  control,  commu¬ 
nications,  and  computer  (C*);  the  team's  consideration  of  d*  expanded  the 
scope  of  the  analysis,  although  the  focus  remained  countermobility  operations. 

4.  Assumptions.  This  report  assumes  that: 

a.  The  development  of  automated  systems  to  support  USAREUR  engineer 
construction  management  and  design  analysis  is  and  will  continue  to  be  done  by 
the  US  Army  Construction  Engineering  Research  Laboratory  (CERL)  and  others. 
These  systems  will  be  applied  mainly  to  those  engineer  activities  in  the  rear 
combat  zone  (RCZ)  that  are  under  the  control  of  echelons  above  corps  (EAC); 
thus,  they  are  considered  "nontactical"  for  the  purposes  of  this  analysis. 
SIGNIFICANCE:  Nontactical  applications  were  not  addressed  by  this  analysis. 

b.  The  development  of  automated  systems  in  USAREUR  is  governed  by 
Department  of  the  Army  Headquarters  (DAHQ)  policy  and  guidance  given  in  the 
Army  Regulation  (AR)  18  series,  related  regulations  and  technical  bulletins, 
and  approved  Army-wide  automation  plans.  SIGNIFICANCE:  Army  guidance 
establishes  feasible  courses  of  action. 


5.  Objectives.  The  objectives  of  this  analysis  were  to: 

a.  Identify  data  and  information  processes  engineer  commanders  and 
their  staffs  use  in  the  FCZ  during  peacetime  and  wartime  that  can  be  improved 
by  exploiting  computers,  communications,  and  related  technologies. 

b.  Develop  general  specifications  for  the  potential  ACEOPS  applica¬ 
tions. 

c.  Prepare  a  draft  functional  requirements  specification  for  identi¬ 
fied  ACEOPS  applications. 

d.  Describe  the  Command  and  Control  Subordinate  System  (CCS^)  con¬ 
cept  as  it  relates  to  the  engineer  functional  area. 

e.  Describe  an  echeloned  ACEOPS  structure  compatible  with  the  CCS^ 
concept,  Including  Interfaces,  network  linkages,  and  minimum  node  capabilities 
for  the  engineer  functional  area. 

f.  Identify  and  evaluate  courses  of  action  which  the  USAREUR  DCSENGR 
could  pursue  to  obtain  ACEOPS  capability. 

6.  Approach. 

a.  Literature  search.  An  extensive  literature  search  was  conducted 
to  identify  documents  relevant  to  the  study  purpose  and  scope.  Pertinent 
reports,  regulations,  and  plans  from  sources  in  USAREUR,  DA,  major  Army  com¬ 
mands  (MACOMs),  and  contractors  were  acquired  and  reviewed. 

b.  User  questionnaire.  A  questionnaire  was  developed  and  adminis¬ 
tered  to  engineer  planners  in  HQ  USAREUR,  V  Corps,  and  VII  Corps.  The  ques¬ 
tionnaire  sought  user  opinions  about  COPS  specifically,  and  battlefield  auto¬ 
mation  needs  in  general.  The  questionnaire  was  followed  up  by  a  field  trip  to 
USAREUR;  during  the  trip,  combat  engineer  automation  needs  were  discussed  with 
HQ  USAREUR,  the  V  and  VII  Corps  representatives,  and  others. 


c.  Interviews.  Points  of  contact  at  Amy  organizations  in  the 
United  States  involved  with  battlefield  automation  planning  and  developmental 
activities  were  interviewed  at  various  times  throughout  the  project. 
Interviews  were  repeated,  as  necessary,  to  keep  abreast  of  the  latest  automa¬ 
tion  developments. 

d.  Participation  in  CCS^  activities.  Study  team  members  partici¬ 
pated  in  CCS^  working  groups  at  the  Combined  Arms  Center  (CAC),  Fort  Leaven¬ 
worth,  and  at  the  United  States  Amy  Engineer  School  (USAES),  Fort  Belvoir, 
during  the  course  of  the  study.  The  main  purpose  for  the  participation  was  to 

ascertain  how  and  to  what  extent  the  needs  of  combat  engineers  in  USAREUR  were 
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being  considered  in  the  CCS  concept. 


II.  FINDINGS 


7.  ACEOPS  Feasibility.  Existing  and  developmental  automation  technology 
provides  seemingly  unlimited  opportunities  for  USAREUR  to  enhance  both  its 
peacetime  and  wartime  planning  and  the  way  in  which  it  executes  combat  engi¬ 
neer  functions.  It  is  entirely  possible  to  automate  essential  planning  and 
operations  activities;  however,  what  can  be  achieved  in  the  way  of  combat  eng¬ 
ineer  automated  systems  depends  on  the  total  force's  automation  needs  on  the 
battlefield. 


a.  The  ACEOPS  requirements  for  wartime  conditions  are  the  most 
demanding.  Thus,  the  specifications  developed  to  meet  wartime  needs  are 
expected  to  result  in  a  system  that  is  flexible  enough  to  satisfy  peacetime 
requirements.  For  that  reason,  this  analysis  emphasized  automation  concepts 
and  plans  for  the  battlefield. 

b.  The  capabilities  and  characteristics  of  state-of-the-art  hardware 
and  software  make  it  possible  to  provide  automation  resources  (or  access  to 
these  resources)  at  all  echelons  in  the  force.  The  more  significant  capabili¬ 
ties  and  characteristics  from  an  ACEOPS  perspective  include: 

(1)  Relatively  small,  portable,  reliable,  and  easily  linked 
hardware  devices.  These  would  ensure  timely  information  exchanges,  and  give 
engineer  units  computation  and  analysis  capability. 

(2)  Distributed  data  bases  and  innovative  data  base  management 


systems. 

(3)  Multiple  display  and  output  methods,  including  video  graph¬ 
ics  and  text,  hardcopy'  graphics  and  text,  and  electronic  mall. 

(4)  Simple  operator  techniques  (minimal  training). 

(5)  Multiple  interface  and  power  source  options. 
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c.  Tailoring  ACEOPS  (or  an  ACEOPS  subsystem  for  USAREUR,  such  as 
COPS)  to  engineer  forces  now  deployed  with  the  V  and  VII  Corps  would  improve 
peacetime  planning.  It  would  not,  however,  be  desirable  from  a  wartime  stand¬ 
point,  since  augmentation  units  would  not  be  equipped  or  trained  to  use  the 
system.  For  this  reason,  ESC  decided  the  most  desirable  approach  would  be  to 
design  ACEOPS  so  its  requirements  were  the  same  or  similar  to  those  of  the 
Army-wide  engineer  systems  now  being  developed. 

8.  ACEOPS  in  Perspective.  The  automation  of  engineer  functional  activi¬ 
ties  is  included  in  Army-wide  plans  and  concepts  for  c\  Many  organizations 
are  involved  in  developing  C^  plans  and  concepts  at  HQDA,  MACOM,  and  subordi¬ 
nate  levels.  ESC  interviewed  key  action  officers,  reviewed  the  plans  and 
conceptual  systems  (and  field  test  results  of  these  systems),  and  found  that: 

a.  The  combat  engineer  C^  must  be  consistent  with  the  approved  CCS^ 

o 

concept.  The  CCS  concept  establishes  the  structure  and  architecture  for  the 
tactical  portion  (corps  and  below)  of  the  Army  Command  and  Control  Master  Plan 
(AC^MP).1  It  focuses  on  the  information  flow  to  and  from  the  maneuver  com¬ 
mander  on  the  battlefield  (within  a  given  hierarchical  structure),  and  empha¬ 
sizes  the  use  of  automation  to  improve  decisions.  The  combat  engineer  mission 
area  is  included  in  the  CCS^  concept.  (See  Annex  A  for  a  more  detailed 

discussion  of  CCS^  and  AC^MP.) 

2 

b.  The  CCS  architecture  and  development  program  is  flexible  enough 
to  allow  the  use  of  the  latest  technological  advances  in  meeting  engineer 
mission  area  needs.  The  concept  requires  input  (either  manual  or  automated) 

^Department  of  the  Army,  Office  of  the  Chief  of  Staff,  Army,  Office  of 
the  Deputy  Chief  of  S$aff  for  Operations  and  Plans,  The  Army  Command  and  Con- 

,  Washington,  D.  C. ,  1979  (SECRET)  (hereafter 


trol  Master  Plan  (AC  MP)  (U) 
referred  to  as  AC^MP). 


from  each  of  the  mission  areas  supporting  the  force  commander.  The  functional 
commander  (e.g. ,  the  engineer)  also  is  generally  free  to  develop  whatever  he 


needs  for  functional  staff  and  command  purposes,  provided  basic  CCS^  concept 
characteristics  are  maintained.  Such  basic  characteristics  include  hardware 
and  software  compatibility,  interoperability,  and  standardization. 

2 

c.  Significant  progress  has  been  made  in  the  development  of  CCS  . 

Recently,  tactical  computer  systems  (TCSs)  and  tactical  computer  terminals 

2 

(TCTs)  were  tested  in  USAREUR  units — a  hey  step  in  the  development  of  the  CCS 
maneuver  control  system.  Based  on  test  results,  initial  procurement  was 
approved.  Current  estimates  call  for  a  full  CCS  by  1990. 

(1)  Besides  maneuver  control,  major  CCS^  components  are  air 
defense,  fire  control,  combat  service  support,  and  intelligence  and  electronic 
warfare.  Engineers  are  included  mainly  in  maneuver  control  and  intelligence 
and  electronic  warfare.  Unfortunately,  engineer  needs  (i.e.,  specifications 
and  requirements)  do  not  appear  to  have  been  adequately  considered  in  develop¬ 
ments  to  date,  although  the  US  Army  Training  and  Doctrine  Command  (TRADOC)  is 
attempting  to  rectify  that  situation. 

(2)  ESC's  work  on  ACEOPS  is  expected  to  help  the  USAES  and 
others  involved  with  developing  comprehensive  engineer  functional  requirements 
that  will  update  the  AC^MP  and  CCS^. 

d.  Engineer  commanders  and  staffs  must  be  able  to  provide  data  to 
and  receive  data  from  the  major  functional  areas  of  CCS^.  This  can  be  done  by 
integrating  ACEOPS  with  the  functional  controls  via  the  SIGMA  concept  (the 
force  level  control  integrator  at  each  maneuver  echelon).  Those  now  develop¬ 
ing  engineer  systems  therefore  must  consider  CCS^  interface  requirements  at 
each  echelon  in  the  force  hierarchy. 
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e.  The  AC^MP  addresses  system  interfaces.  The  Army  Battlefield 
Interface  Concept  (ABIC)  defines  requirements  for  automated  system  interoper- 
ability  with  CCS^  functional  areas  and  EAC.  Efforts  are  underway  to  identify 
and  develop  interfaces  within  CCS  ,  between  CCS  and  allied  systems,  and 
between  Army  and  other  service  or  national  systems.  An  Interface  also  is 
being  developed  between  the  CCS^  force  level  maneuver  control  system  (i.e. , 
SIGMA)  and  the  allied  systems,  called  HERO  and  WAVELL.  Interfaces  required  at 
EAC  between  Army  systems  and  others,  such  as  the  Central  Army  Group  (CENTAG) 

or  Allied  Forces,  Central  Europe  (AFCENT),  are  within  ABIC's  scope.  Thus,  it 

2 

is  extremely  important  that  combat  engineers  be  included  in  the  CCS  concept 
as  it  evolves,  so  engineer  requirements  are  considered  when  user  interface 
requirements  are  developed. 

9.  USAREUR  Combat  Engineer  Applications.  In  general,  engineers  at  all 
levels  within  USAREUR  want  to  improve  the  timeliness  and  quality  of  the  infor¬ 
mation  they  input  to  the  tactical  decisions  made  by  engineers  and  supported 
commanders.  Rapid  advances  in  small  computer  technology  provide  the  means  to 
Improve  not  only  the  timeliness  and  quality  of  input,  but  also  the  form  of  the 
input  and  the  decision  process  itself.  When  ESC  talked  with  representatives 
from  V  Corps,  VII  Corps,  and  HQ  USAREUR  and  analyzed  the  responses  to  its 
questionnaire,  it  found  that  combat  engineer  automation  needs  can  be  roughly 
grouped  as  standard  or  nonstandard,  peacetime  or  wartime,  and  computation  or 
reporting  (information  transfer). 

a.  Standard  automation  needs  are  those  dictated  by  procedures,  poli¬ 
cies,  and  regulations  established  by  CENTAG,  USAREUR,  or  the  Corps.  (Annex  B 
describes  the  principal  standard  requirements,  with  the  exception  of  those 
systems  associated  with  engineer  topographic  and  terrain  analysis  activities.) 


In  Che  standard  applications,  computers  mainly  facilitate  data  base  management 
and  information  transfer  functions.  Typically,  the  focus  is  on  standard  data 
definitions  and  formats,  common  displays,  specific  update  and  reporting  times, 
information  transfer  networks,  and  compatible  hardware  and  software. 

(1)  Standard  engineer  systems  rely  on  processed  information 
rather  than  raw  technical  data.  Processed  information  is  developed  at  the 
various  echelons  in  the  engineer  structure  by  mostly  nonstandard  processes. 
These  can  be  either  manual  or  automated  and,  in  most  cases,  were  not  developed 
with  standard  system  specifications  in  mind.  Thus,  to  achieve  a  force-wide 
ACCOPS,  these  nonstandard  processes  must  be  adjusted  to  ensure  uniform  defi¬ 
nitions,  data  fields.  Identifiers,  and  other  system  parameters.  Uniformity  is 
best  achieved  by  directive  from  the  highest  applicable  controlling  headquar¬ 
ters  (e.g,  USAREUR,  CENTAG)  and  requires  a  degree  of  compromise,  cooperation, 
and  concession  from  all  concerned.  Once  approved,  force-wide  systems  can  be 
used  to  justify  the  procurement  of  necessary  hardware  and  software  resources. 

(2)  Because  they  are  primarily  reporting  systems,  standard 
application  networks  depend  on  communications  to  input  and  transfer  informa¬ 
tion  among  nodes.  Demands  on  secure,  available  communication  methods  will  be 
great  because  of  the  many  users  expected  on  the  modern  battlefield.  For  this 
reason,  the  developers  of  force-wide  systems  will  be  pressured  to  minimize  the 
need  for  extensive  networks,  so  wartime  communication  resources  are  not  over¬ 
loaded.  Hence,  standard  engineer  systems  provide  the  force  commander  with 
only  the  minimum  essential  engineer  information.  But  engineer  commanders  and 
staffs  must  have  additional  information,  and  the  capability  to  analyze  that 
Information  at  all  levels.  Thus,  engineers  need  local,  largely  nonstandard 
systems.  The  entire  question  of  engineer  communication  support  requirements 


is  now  being  addressed  by  the  USAES  as  part  of  a  TRADOC-wide  analysis  of 
battlefield  communications  requirements. 


b.  All  engineer  elements  within  USAREUR  told  ESC  they  needed  local, 
hands-on  computational  resources.  Those  needs  are  based  mainly  on  peacetime 
planning  and  decisionmaking  requirements.  The  types  of  desired  applications 
vary  widely,  reflecting  the  concerns  of  the  local  commanders  or  staffs. 
(Annex  C  gives  a  more  in-depth  discussion  of  local  applications.) 

(1)  Local  commanders  most  frequently  expressed  a  need  for  compu¬ 
tational  assistance  to  evaluate  alternative  courses  of  action  and  to  perform 
sensitivity  analyses  of  various  planning  options.  Computer  support  is  needed 
to  answer  the  many  "what  if”  questions  involved  In  the  analysis  of  barrier 
material  haul  capability,  the  impact  of  changes  in  task  priorities  on  engineer 
resource  allocations,  and  the  effects  of  various  manpower/equipment/sequence 
combinations  on  mission  completion,  etc. 

(2)  Other  local  needs  include  ways  to  rapidly  and  accurately 
input,  sort,  and  output  data  to  meet  the  information  requirements  of  person¬ 
nel,  operations,  and  logistics  elements.  This  implies  a  capability  to  build 
and  update  data  bases  and  to  generate  reports.  In  addition  to  report  genera¬ 
tion,  most  engineer  unit  headquarters  wanted  a  local  word  processing  capabil¬ 
ity. 

c.  During  wartime,  the  responsiveness  of  combat  engineer  systems  to 
the  data  and  Information  needs  of  the  force  commander  is  the  main  concern. 
During  peacetime,  effective  response  time  can  be  a  matter  of  days  or  weeks; 
during  wartime  it  is  a  matter  of  minutes.  In  wartime,  the  force  commander 
must  be  able  to  get  status  information  and  engineer  estimates  of  the  situation 
very  quickly. 
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(1)  Planned  computer-based  force-level  maneuver  control  systems 
(the  SIGMA  concept)  require  specific  input  from  supporting  engineers.  There¬ 
fore,  V  and  VII  Corps  engineers  must  be  able  to  interface  with  the  maneuver 
control  network.  Systems  developed  and  data  bases  constructed  for  engineers 
must  directly  consider  the  network  and  interface  requirements  of  the  force- 
level  control  systems;  these  systems  are  being  developed  by  CONUS  MACOMs  and 
HQDA  for  Army-wide  implementation.  In  the  context  of  these  development 
activities,  engineer  automation  requirements  can  and  should  be  Included  for 
concurrent  development.  The  USAES  is  the  interface  between  combat  engineers 
and  system  developers. 

(2)  The  availability  and  reliability  of  communications  may  pre¬ 
clude  a  true  engineer  network  with  automated  Interfaces,  particularly  in  war¬ 
time.  It  may  be  necessary  in  some  instances  to  gain  access  through  terminals 
belonging  to  the  supported  maneuver  force.  The  questions  surrounding  avail¬ 
able  communication  resources  during  peacetime  and  wartime  are  also  being 
addressed  at  the  HQDA  and  CONUS  MACOM  level. 

(3)  Most  engineers  in  USAREUR  believe  that  the  nature  of  status 
reporting  in  wartime  calls  for  more  intense  use  of  distributed  data  bases, 
video  displays  (Including  formatted  text,  maps  and  overlays,  and  other 
graphics),  and  record  transfer  (i.e.,  electronic  mail)  of  operations  orders, 
mission  changes,  and  many  kinds  of  reports.  These  kinds  of  capabilities  are 
within  the  current  state-of-the-art  of  small  computers  and  are  included  in 
CCS2. 

10.  Conceptual  ACEOPS.  The  ACEOPS  will  be  a  prototype  engineer  command 
and  control  system  (in  the  broadest  sense).  It  will  be  consistent  with  the 
CCS2  concept.  It  should  serve  three  purposes:  First,  it  will  give  the 


engineers  the  capability  to  process  and  analyze  data  for  internal  command  and 
control  purposes.  Second,  through  an  interface  with  the  maneuver  control  sys¬ 
tem,  it  will  be  an  element  of  the  organization's  command  and  control  network, 
and  will  share  selected  information  with  other  control  systems.  Third,  it 
will  produce  key  command- related  information  to  support  the  force  commander's 
decision  process.  ACEOPS  will  have  the  same  characteristics  as  those  speci¬ 
fied  in  the  CCS^  and  architecture,  and  as  described  in  the  AC^MP.  Both  its 
hardware  and  software  will  be  subject  to  Army-wide  configuration  management 
policies.  The  proposed  ACEOPS  will  allow  USAREUR  engineers  to  enter  the  CCS^ 
development  process  and  bring  user  influence  to  bear  on  those  responsible  for 
AC^MP  execution. 

a.  The  ACEOPS  will  interface  directly  with  the  CCS^  maneuver  control 
system  via  the  SIGMA  network;  in  fact,  it  is  expected  to  be  a  maneuver  control 
subsystem  (see  Figure  1).  At  engineer  battalion  level  and  higher, 
microcomputer-based  terminals  will  provide  input,  output,  and  stand-alone 
computational  capability.  At  engineer  company  level  and  lower,  there  may  be 
input/output-only  devices  linked  to  the  parent  microcomputer  terminal;  stan¬ 
dard  communications  also  can  be  used  (e.g.,  radios,  wire,  courier).  In  accor¬ 
dance  with  Army  policy,  the  equipment  specifications  for  all  components  will 
comply  with  established  technical  baselines. 

b.  Measures  of  performance  for  the  ACEOPS  will  be  comparable  to 
other  command  and  control  systems  and  subsystems.  That  is,  ACEOPS  will  be 
able  to  handle  high  volumes  of  information,  distribute  data  rapidly  and  simul¬ 
taneously  to  multiple  nodes,  process  information,  interoperate  through  stan¬ 
dardization  and  linkage  to  ensure  continuity  of  operations,  and  survive  much 
the  same  as  other  tactical  systems. 


CCS2-  ACEOPS  LINKAGE 


*SOURCE:  Department  of  the  Army,  US  Army  Training  and  Doctrine  Command,  US  Army  Combined  Arms 
Combat  Development  Activity,  Army  Command  and  Control  Master  Plan  Update  With  Mission  Area  Analysis 
(U) ,  Fort  Leavenworth,  Kansas,  December  1982  (SECRET)  (hereafter  referred  to  as  CACDA  AC*MP  Update), 


c.  Since  the  ACEOPS  concept  calls  for  microcomputer  capability  com¬ 
parable  to  current  TCT  at  battalion  level — and  possibly  minicomputers  similar 
to  the  TCS  at  brigade  level — engineers  could  accommodate  peacetime  nonstandard 
analytic  requirements.  This  capability  would  be  constrained  during  peacetime 
only  by  the  programming  and  computer  skills  of  available  personnel. 

d.  ESC  did  not  consider  the  needs  of  engineer  topographic  elements 
when  developing  the  ACEOPS  proposal,  since  those  elements  interface  directly 
with  the  intelligence  and  electronic  warfare  (I/EW)  control  system,  not  the 
maneuver  control  system.  The  Engineer  Topographic  Laboratories  (ETL)  also 
have  a  number  of  systems  under  development,  principally  the  Digital  Topo¬ 
graphic  Support  System  (DTSS),  for  topographic  engineers.  And  as  part  of  the 
ABIC,  efforts  are  underway  to  establish  an  Interface  between  DTSS  and  the 
I/EW's  All  Source  Analysis  System  (ASAS).  Ultimately,  however,  ACEOPS  will 
interface  with  ASAS  and  DTSS  through  the  SIQiA  network. 

e.  The  essential  hardware  and  software  characteristics  already 
Included  in  overall  CCS^  concepts  should  be  adequate  for  ACEOPS.  No  special 
or  unique  requirements  have  been  identified.  Including  ACEOPS  in  CCS^,  and 
involving  combat  engineers  as  full  participants  in  developmental  activities 
through  the  USAES,  is  the  most  practical  way  to  assure  that  automated  system 
capability  is  acquired  by  combat  engineers.  Such  an  approach  is  consistent 
with  Army  policy. 


14 


III.  SUMMARY  AND  RECOMMENDATIONS 


11.  Summary.  The  development  and  acquisition  of  automated  systems  to 
facilitate  the  execution  of  combat  engineer  tasks  both  in  peacetime  and  war¬ 
time  is  feasible,  desirable,  and  necessary.  However,  developing  and  resourc¬ 
ing  a  single-purpose  system  (such  as  COPS)  for  only  a  part  of  the  combat 
engineer  tactical  mission  area  does  not  appear  to  be  acceptable  or  practical. 

a.  There  is  Intense  and  widespread  interest  at  HQDA  and  in  the  com¬ 
bat  and  material  development  communities  in  using  computers  to  help  commanders 
on  the  tactical  battlefield.  In  recent  years,  considerable  resources  have 
been  committed  to  concept  and  hardware  evaluation  as  well  as  to  the  analysis 
of  processes  which  can  be  improved  through  automation.  The  concepts,  archi¬ 
tecture,  and  structure  now  approved  for  Army-wide  tactical  are  described  in 
the  AC2MP. 

(1)  The  concepts  and  structure  of  CCS2  require  combat  engineers 
to  provide,  either  manually  or  through  an  automated  system,  certain  key  inputs 
to  the  force  control  process.  These  inputs  are  mainly  combat  engineering  data 
for  the  CCS  maneuver  control  system  and  topographic  engineering  data  for  the 
I/EW's  control  systems.  Development  of  engineer  systems  as  part  of  the  CCS2 
concept  is  consistent  with  Army  policy  and  would  ensure  integrated  development 
efforts  toward  a  common  goal. 

(2)  Within  the  TRADOC  community,  the  USAES  has  initiated  actions 
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to  assure  consideration  of  combat  engineer  automation  requirements  as  the  CCS 
concept  evolves.  The  USAES  has  succeeded  in  having  engineers  included  in  the 
nondevelopmental  item  follow-on  purchase  for  TCS-  and  TCT-type  hardware,  with 
an  FY  87  initial  operational  capability  (IOC).  Although  much  remains  to  be 


done,  the  USAES  is  actively  participating  in  various  AC^MP  Implementation 
forums  throughout  the  combat  and  material  development  communities. 

(3)  While  hardware  prospects  are  improving,  little  has  been  done 
to  tailor  software  to  combat  engineer  needs.  The  USAES  is  in  the  best  posi¬ 
tion  to  interject  engineer  requirements  as  SIGMA  and  other  CCS^  software  are 
developed. 

b.  The  CCS^  concept  focus  is  on  wartime  systems.  Both  hardware  and 
software  developments  are  aimed  at  satisfying  wartime  criteria  dictated  by  the 
needs  of  the  force  commander.  The  resulting  systems  and  resources  provided  to 
functional  participants,  including  engineers,  are  expected  to  be  flexible 
enough  to  satisfy  unique  peacetime  functional  requirements  that  may  not  be 
Included  in  the  standard  wartime  system. 

c.  The  likelihood  that  systems  such  as  ACEOPS  could  be  developed  and 
resourced  on  a  stand-alone  basis,  separate  from  CCS  developments,  is  not 
good.  Such  an  endeavor  would  violate  the  criteria  underlying  the  AC^MP. 
Significant  among  these  criteria  are:  standardization  of  hardware,  software, 
and  computer  languages;  systems  interface  and  integration;  communication 
resource  allocation  and  control;  and  perhaps  most  readily  apparent, 
affordability. 

12.  Recommendations.  This  analysis  did  not  attempt  to  capture  all  of 
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the  details  of  the  many  efforts  underway  in  AC  MP  implementation  and  battle¬ 
field  automation  programs.  Given  the  rapid  changes  in  the  C^  area  of  develop¬ 
ment,  efforts  to  be  more  precise  would  be  of  doubtful  value.  Rather,  the 
analysis  focused  on  identifying  those  factors  which  must  be  considered  if 
USAREUR  combat  engineer  automation  needs  are  to  be  met.  This  approach  led  to 
the  following  recommendations: 


a.  Combat  engineer  automation  requirements  should  be  met  by  exploit- 
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ing  the  provisions  of  the  AC  MP  and  CCS  concept.  The  plan  and  concept  have 
received  HQDA  approval;  thus,  they  command  the  attention  of  the  combat  and 
material  development  communities,  who  are  most  likely  to  receive  the  resources 
and  priority  effort  needed  to  achieve  orderly  and  early  system  development. 
(It  is  expected  that  USAREUR  engineers  will  be  included  in  the  TCS  and  TCT 
nondevelopmental  item  follow-on  purchase,  with  an  IOC  of  FY  87.)  This  course 
of  action  requires  that: 

(1)  USAREUR  combat  engineer  system  functional  requirements  spec¬ 
ifications  be  submitted  to  TRADOC  (through  the  USAES)  for  inclusion  in  the 
system  development  process.  This  should  be  done  now,  since  CCS^  developments 
are  well  underway.  Annex  B  can  be  used  as  is  (or  be  further  refined)  for  this 
purpose. 

(2)  USAREUR  engineer  representation  be  established  immediately 
and  maintained  in  the  C^  concept  evaluation  and  development  activities  within 
the  command  to  assure  that  engineer  needs  are  considered. 

(3)  USAREUR  and  corps  engineer  staffs  should  maintain  (or 
initiate,  if  necessary)  frequent  contact  with  the  USAES  to  provide  the  inputs 
needed  to  ensure  an  appropriate  basis-of-issue  for  hardware,  and  to  influence 
overall  ACEOPS  developments.  Conversely,  the  USAES  must  actively  involve 
USAREUR  and  the  corps  in  the  ACEOPS  development  process. 

b.  Engineer  automation  requirements  should  be  oriented  toward  war¬ 
time  needs  as  part  of  combined  arms  battlefield  automation  initiatives,  not 
toward  Independent  engineer-unique  systems.  Given  the  state  of  battlefield 
automation  developments,  it  is  unlikely  that  independent  systems  will  have 
sufficient  justification  to  obtain  the  required  approvals  or  development 
resources.  Hardware  procured  and  issued  as  part  of  battlefield  systems  such 


as  SIGMA  will  have  the  capability  and  flexibilty  to  accommodate  peacetime  and 
specialized  engineer  automation  needs. 

c.  CERL  should  be  considered  a  prime  candidate  for  ACEOPs  software 
development.  It  has  proposed  a  research  and  development  program  which 

includes  the  ACEOPs  concepts  and  functions,  and  which,  if  adequately  funded, 

2  2 

can  be  completed  in  sync  with  other  CCS  and  AC*MP  developments. 
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Purpose.  This  annex  summarizes  the  AC  MP, 

highlighting  those 

elements 

that  establish  a  framework  within  which  automated 

combat  engineer 

systems 

can  be  developed.  The  intent  is  to  acquaint 

the 

reader  with  the 

approved 

mechanism  for  the  orderly  development  and  integration  of  C4  systems 

throughout  the  Army 
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2.  General.  The  AC  MP  provides  Army-wide  direction  for  command  and  con¬ 
trol  planning  and  systems  development.  The  plan  is  a  functional  framework  for 
expressing  the  Army  Command  and  Control  System  (ACCS)  architecture  and 
describes,  in  detail,  the  tactical  (corps  and  below)  portion  of  the  architec¬ 
ture.  It  delineates  known  deficiencies  and  identifies  responsibilities  and 
milestones  for  ACCS  development.  The  plan  is  updated  periodically  to  incor¬ 
porate  changes  in  threat,  doctrine,  tactics,  and  force  structure.  It  is 
intended  for  use  at  all  levels  to  ensure  a  coordinated  effort  in  attaining 
ACCS  objectives.  The  AC^MP  includes: 

a.  An  ACCS  architecture  assessment.  The  ACCS  architecture  is 
described  as  sets  of  elements  categorized  according  to  each  ACCS  system  ele¬ 
ment  (e.g.,  communications,  data  collection  and  processing,  intelligence  sur¬ 
veillance  and  target  acquisition,  facilities,  and  command  aids)  across  each 

2 

CCS  battlefield  functional  area.  These  areas  are:  maneuver,  fire  support, 
air  defense,  intelligence,  and  combat  service  support.  Known  ACCS  deficien¬ 
cies  identified  by  functional  system  program  reviews,  mission  area  analyses, 
and  other  DA  analyses  are  summarized.  These  deficiencies  form  the  basis  for 
specific  corrective  actions  described  in  a  system  development  plan. 

b.  ACCS  Capability  Requirements  (ACRs).  An  ACR  is  a  validated  com¬ 
mand  and  control  initiative  to  correct  known  deficiencies  in  the  ACCS.  The 
ACRs  are  developed  (and  periodically  updated)  to  reflect  statements  of  tacti¬ 
cal  requirements  which  must  be  met  to  ensure  that  command  and  control  tasks  in 
support  of  the  modern  battlefield  are  performed  well.  These  ACRs  are  inputs 
to  the  system  development  plan. 

c.  Army  Command  and  Control  System  Development  Plan  (ACCSDP).  This 
is  the  approved  Army-wide  plan  jointly  prepared  by  TRADOC  and  the  US  Army 
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Material  Development  and  Readiness  Command  (DARCOM).  It  presents  actions, 
responsibilities,  and  milestones  for  correcting  known  deficiencies  at  the 
tactical  echelons  of  the  ACCS  architecture.  Corrective  actions  are  programmed 
against  deficiencies  resulting  from  ACCS  assessments,  ACRs,  and  action  plans 
resulting  from  mission  area  analyses.  The  ACCSDP  tasks  combat  and  material 
developers,  as  well  as  ACR  proponents. 

d.  ACCS  Management  Plan.  The  management  plan  describes  the  struc¬ 
ture,  responsibilities,  and  actions  required  to  administer  the  complex  imple¬ 
mentation  process  involving  the  development  and  integration  of  the  component 
systems  of  the  ACCS  architecture. 

3.  The  Army  Command  and  Control  System.  The  ACCS  is  a  system  of  system 
networks  which  supports  commanders  at  all  levels  in  commanding  their  forces, 
and  which  assists  the  staff  at  all  levels  in  controlling  their  functions  in 
support  of  the  commanders.  The  ACCS  supports  all  phases  of  war  from 
premobilization  to  sustainment.  The  ACCS  is  the  Army's  all-encompassing, 
integrated  system  of  automation  and  communications  systems,  procedures,  and 
facilities.  It  integrates  individual  system  networks  at  the  sustaining  base 
and  at  strategic,  theater,  and  tactical  echelons,  and  interfaces  with  other 
service  and  allied  (e.g.,  NATO)  systems.  Recent  efforts  have  concentrated  on 
ACCS  development  at  the  tactical  (corps  and  below)  echelon. 

a.  Tactical  architecture.  The  CCS  concept  (see  Figure  A-I)  is  the 
approved  Army  tactical  command  and  control  structure  and  objective  architec¬ 
ture  for  the  tactical  portion  of  the  AC^MP.  It  focuses  on  the  information 
flow  to  and  from  the  maneuver  commander  on  the  battlefield  within  a  given 
hierarchical  structure.  Within  each  level  (company  through  corps),  the 
battlefield  has  been  divided  into  the  five  functional  areas:  maneuver,  fire 
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support,  air  defense,  combat  service  support,  and  intelligence  and  electronic 
warfare.  All  mission  areas  are  included  in  these  five  nodes.  Some  mission 
areas  are  common  to  all  nodes  while  others  are  not.  Combat  engineering,  for 
example,  is  included  mainly  in  the  maneuver  node.  The  CCS  concept  includes 
the  structure  necessary  to  collect,  process,  and  transmit  among  all  elements 
information  required  for  planning,  directing,  and  executing  at  each  echelon. 
Each  of  the  five  nodes  has  a  control  system  that  ties  together  any  number  of 
manual  or  automated  mission  area  subsystems.  The  nodes  are  linked  by  a  force 
control  system  called  SIGMA.  SIGMA  is  represented  by  the  star  and  pentagram 
in  Figure  A-l. 

(1)  The  force  control  system  allows  functional  control  systems 
to  share  information;  it  is  responsive  to  the  force  commander  (primarily 
through  the  maneuver  control  system)  and  has  software,  communications,  and 
data  distribution  capability.  It  ties  the  five  functional  areas  of  the  bat¬ 
tlefield  together  and  provides  the  commander  with  critical  information  for 
decisionmaking. 

(2)  The  force  level  system,  SIGMA,  is  closely  associated  with 
the  functional  control  systems.  It  establishes  the  linkage  which  assures  con¬ 
tinuity  of  operations  by  enforcing  standardization  and  interoperability,  and 
by  providing  for  distributed  data  bases  and  distributed  data  processing. 

b.  The  CCS^  architecture  requires  an  extensive  d  architecture.  The 
general  nature  of  the  architecture  needed  to  link  the  five  functional 
control  systems  and  their  subsystems  is  shown  by  the  overlapping  circles  in 
Figure  A-2.  Depending  on  the  level  in  the  battlefield  command  hierarchy, 
different  capabilities  (devices  and/or  systems)  are  used  to  fulfill  the  d 
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(1)  The  total  requirement  is  very  complex.  For  every  force 
level,  there  are  multiple  commands  and  multiple  echelons  all  requiring  dis¬ 
tributed  communications  and  interconnected  computers.  The  geometric  nature  of 
the  C4  requirement  generated  by  the  CCS^  architecture  is  depicted  in  Figure 
A-3.  A  structure  has  been  proposed  providing  tactical  units  from  corps  to 
company  level  with  an  extensive  combat  net  radio  system,  access  to  an  auto¬ 
mated  switched  common  user  system,  a  near-real-time  data  distribution  system, 
and  a  mobile  subscriber  system.  If  system  procurement  remains  on  track,  the 
basic  structure  will  be  achieved  by  1987. 

(2)  The  AC^MP  recognizes  how  critical  C4  support  is  and  the 
extensive  interoperability  and  interfacing  challenges  created  by  the  CCS  . 
These  issues  are  being  resolved  by  the  ABIC.  The  ABIC  defines  interface 
requirements  between  automated  systems  at  corps  and  below  and  for  those  joint, 
allied,  and  national  systems  that  provide  information  to  or  exchange  informa¬ 
tion  with  corps  automated  systems.  ABIC  results  in  an  interface  development 
schedule  which  is  reviewed  and  updated  annually.  The  latest  review,  in 
September  1983,  included  99  different  automated  systems  (Army  ■  67,  Navy  *  3, 
Air  Force  *  11,  Marine  *  6,  National  *  1,  Allies  ■  11). 

c.  ACCS  implementation.  The  ACCSDP  and  the  ACCS  Management  Plan 
provide  for  a  phased,  controlled,  and  evolutionary  transition  from  the  current 
battiefield  automation  posture  to  a  posture  reflecting  the  ACCS  objectives. 
The  steps,  tasks,  milestones,  and  priorities  are  established,  based  on  how 
critical  the  ACRs  are  and  on  a  consideration  of  interface  and  interoperability 
requirements.  The  status  of  the  implementation  plan  is  frequently  reviewed 
and  updated  to  account  for  new  requirements,  resource  availability,  test  and 
evaluation  results,  and  changes  in  priority.  Implementing  the  ACCS  creates  a 


significant  management  challenge 
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Army  is  required  to  successfully  implement  the  ACCS.  The  management  approach 
exploits  the  existing  Army  management  structure  to  gain  broad  consensus  and 
support  throughout  the  Army.  Figure  A-4  depicts  a  top-level  view  of  the  ACCS 
management  structure. 

a.  Major  implementation  actions.  The  assignment  of  responsibility 
for  major  ACCS  implementation  actions  is  shown  in  Figure  A-5.  HQDA  is  the 
ACCS  program  manager,  TRADOC  is  the  ACCS  system  architect,  and  DARCOM  is  the 
ACCS  systems  engineer.  The  ACCS  Management  Plan  identifies  specific  implemen¬ 
tation  task  responsibilities  of  these  and  other  organizations,  and  establishes 
a  master  schedule  for  task  accomplishment.  Key  roles  are: 

(1)  HQDA.  The  Deputy  Chief  of  Staff  for  Operations  and  Plans 
(DCSOPS)  exercises  general  staff  responsibility  for  the  ACCS.  The  Assistant 
DCSOPS  for  Command,  Control,  Communications,  and  Computers  (ADCSOPS-C^)  is 
responsible  for  managing  and  coordinating  the  ACCS  program.  This  task  entails 
coordinating  policy;  establishing  ACCS  priorities;  ensuring  that  planning, 
programming,  and  budgeting  system  (PPBS)  actions  are  accomplished;  supervising 
the  overall  accomplishment  and  status  of  implementation  actions;  and  adminis¬ 
tering  the  activities  of  the  ACCS  Council  established  by  AR  15-21. 1 

(2)  TRADOC.  TRADOC  is  the  lead  combat  developer  for  the  com¬ 
ponent  systems  that  comprise  the  ACCS.  In  addition,  TRADOC,  with  the  Combined 
Arms  Combat  Development  Activity  (CACDA)  as  executive  agent,  is  designated  the 
ACCS  architect.  This  job  includes  modifying  the  ACCS  architecture  for  signif¬ 
icant  changes  in  programs,  priorities,  or  the  threat;  expanding  the  scope  of 

*  Department  of  the  Army,  Headquarters,  AR  15-21,  Army  Command  and  Control 
Council,  Washington,  D.  C. ,  4  May  1977  (UNCLASSIFIED). 
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Che  architecture  as  needed  to  encompass  additional  command  and  control 
systems;  developing  interoperability  concepts  and  requirements  documentation; 
and  planning  or  participating  in  ACCS  operational  and  force  development  test¬ 
ing  and  experimentation.  To  accomplish  these  tasks,  TRADOC  is  given  authority 
over  other  Army  combat  development  activities  and  user  representatives.  In 
addition,  TRADOC  develops,  consolidates,  and  updates  the  combat-development- 
related  sections  of  the  AC^MP. 

(3)  DARCOM.  DARCOM  is  the  lead  material  developer  for  the 
acquisition  of  ACCS  component  systems.  DARCOM,  with  the  Center  for  Systems 
Engineering  and  Integration  (CENSEI)  as  the  executive  agent,  is  the  ACCS  sys¬ 
tems  engineer.  In  this  role,  DARCOM  develops  ACCS  specifications  and  super¬ 
vises  adherence  to  established  standards.  This  job  includes  designing  inter¬ 
operability  standards,  implementating  component  ACCS  systems,  and  doing  ACCS 
developmental  tests  and  experimentation.  DARCOM  develops  and  updates  the  ACCS 
material-development-related  sections  of  the  AC  MP. 

(4)  Others.  Commanders  of  other  MACOMs,  heads  of  staff  agen¬ 
cies,  and  commanders  of  Army  components  of  unified  and  specified  commands 
(e.g.,  USAREUR) ,  develop  plans  for  ACCS  elements  within  their  command  that  are 
consistent  with  the  total  ACCS  architecture  and  systems  specifications.  They 
coordinate  ACCS  combat  and  material  development  with  TRADOC  and  DARCOM,  main¬ 
taining  points  of  contact  with  appropriate  staff  elements  involved  with  new  or 
approved  doctrine,  organizations,  techniques,  and  material.  In  addition,  they 
are  responsible  for  developing  statements  of  required  operational  capability, 
functional  specifications  and  mission  needs  (as  appropriate),  and  forwarding 
them  to  the  ACCS  system  architect. 


b.  Management  guidance  and  direction.  The  ACCS  management  structure 
receives  guidance  and  direction  from  the  Army  Command  and  Control  Council 
(supported  by  a  steering  committee  and  working  group).  It  provides  executive- 
level  management  and  coordination  of  ACCS  activities.  The  steering  committee 
and  working  group  provide  guidance  on  program  objectives,  coordinate  MACOM 
activities,  and  resolve  issues.  HQDA,  as  ACCS  program  manager,  provides 
policy,  guidance,  and  direction  at  key  times  in  the  AC  MP  update  cycle  to 
assure  that  it  is  consistent  with  PPBS  activities  and  milestones. 

5.  AC  MP  Developments.  There  is  an  extremely  large  number  of  actions 
underway  to  develop  the  approved  ACCS  architecture.  As  stated,  the  actions 
are  aimed  at  a  controlled  and  orderly  transition  from  the  existing  manual  and 
automated  systems  to  the  ACCS  objective  system.  In  general,  it  is  an  evolu¬ 
tionary  development  process.  This  process  is  defined  as  the  phased  develop¬ 
ment  and  early  fielding  of  system  subcapabilities  according  to  a  prioritized 
plan.  The  ultimate  objective  is  to  satisfy  a  set  of  known  fixed  requirements, 

yet  permit  the  specification  of  additional  requirements  during  development. 

y 

With  regard  to  the  CCS  and  SIGMA,  strides  have  been  made  toward  objective 
systems  for  maneuver,  combat  service  support,  and  intelligence  and  electronic 
warfare  control.  Developments  in  the  maneuver  control  area,  including  distri¬ 
bution  of  hardware  capability,  are  of  immediate  interest  to  combat  engineers. 

a.  Maneuver  control  system  developments.  A  typical  US  corps  (three 
divisions  and  one  armored  cavalry  regiment)  characteristically  has  a  command 
(G3/S3)  information  flow  (see  Figure  A-6).  Actions  are  underway  to  automate 
the  information  flow  by  placing  independent  computing  and  processing  devices 
at  each  node  to  receive,  transfer,  store,  process,  retrieve,  a\  '-int  using 
existing  and  projected  communications  equipment.  The  structure  will  have 
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automated  assistance,  but  will  not  be  a  true  automated  network  until  the 
interfaces  and  linkages  are  established.  Much  effort  is  still  required  on  the 
force  level  system  (SIGMA),  indicated  in  Figure  A-6  by  the  dashed-line 
pentagram.  Like  the  maneuver  control  system,  each  of  the  other  four  control 
systems  will  have  intricate  networks  of  supporting  subsystems.  The  depicted 
maneuver  control  system  is  expected  to  be  achieved  by  FY  87  and  the  complete 
CCS2  by  FY  90. 

(1)  The  kinds  of  hardware  now  planned  for  the  maneuver  control 
system  consist  of  independent  devices.  Currently,  the  TCS,  TCT,  three  nonde- 
velopmental  items  (NDI),  and  a  militarized  battalion-level  processor/ computer 
device  (BLD)  are  being  considered  as  standard.  The  objective  CCS  structure 
provides  for  C^  needs  from  company  to  corps.  The  extent  of  the  current  maneu¬ 
ver  control  system,  however,  will  be  constrained  by  available  communications 
equipment  and  the  number  of  devices  at  each  level  in  the  hierarchy. 

(2)  In  October  1983,  CAC  conducted  an  analysis  of  automated 

terminals  and  workstations  as  part  of  the  Battlefield  Communications  Review. 

CAC  verified,  prioritized,  and  documented  the  essential  characteristics  of  a 

general  battlefield  data  processing  terminal  and  workstation  for  use  by  con- 

o 

trol  systems  within  the  CCS  architecture.  The  analysis  concluded  that  the 
Army  should  constrain  itself  to  using  the  TCS,  TCT,  maneuver  control  system 
NDI,  single  subscriber  terminal  (SST),  and  Tactical  Army  CSS  Computer  System 

(TACCS)  until  the  military  computer  family  is  fielded. 

2 

b.  CCS  microprocessor  requirements.  The  SIGMA  Combat  Development 
Support  Facility  at  CAC  has  evaluated  ways  to  reduce  microprocessor  prolifera¬ 
tion  and  redundancy  on  the  battlefield,  while  ensuring  that  mission-essential 
requirements  are  fulfilled.  Based  on  the  CCS  architecture,  minimum  essential 
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characteristics  of  generic  microprocessors  and  workstations  were  identified, 
and  the  capability  of  existing  and  developmental  hardware  to  fulfill  the 
requirement  was  assessed. 

(i)  At  a  minimum,  battlefield  microprocessor  terminals  and  work¬ 
stations  will: 

(a)  Be  supportable  at  reasonable  cost  within  the  Army  main¬ 
tenance  structure  in  time  of  war. 

(b)  Be  easily  maintainable  by  Army  personnel  (e.g. ,  "green 
suit  supportability" ) . 

(c)  Provide  a  graphics  function,  decision  graphics  capabil¬ 
ity,  and  a  printer  capable  of  alpha-numerics  and  graphics. 

(d)  Provide  an  expandable  data  base  management  system  (min¬ 
imum  512  kilo-bytes  internal  storage). 

(e)  Provide  for  full  memory  retention  and  overflow  storage. 

(f)  Provide  for  message  composition  of  standard  message 
width  (i.e.,  80  characters). 

(g)  Possess  communication  capabilities  for  ITA-2  BAUDOT;  2 
and  4  wire;  FM;  AM;  multichannel  (digital  and  voice);  independent  channels  of 
75,  150,  300,  600,  1200,  2400,  4800,  8000,  9600,  and  16000  BPS  data  rates; 
FSK/di-phase/NRZ  electronic  interfaces;  programmable  protocals;  and  a  packet 
radio  switch  system. 

(h)  Provide  primary  man-system  interface  capability  for 
control  of  messages,  graphics  composition,  transmission,  and  reception. 

(i)  Use  ADA  and  other  Army-approved  high  order  languages. 

(j)  Be  capable  of  being  installed  and  operate  in  M577  , 


CUCV,  HMMUV,  and  S-250. 


(k)  Not  impede  unit  operations  during  set-up  or  tear-down. 

(l)  Utilize  bulk  encryption  devices. 

(m)  Be  air,  water,  and  ground  transportable  in  carrying 


cases  as  loose  cargo. 

(n)  Survive  blast  and  fragmentation  effects,  at  least  as 
well  as  the  other  equipment  used  with  it. 

(o)  Be  built  around  a  general  purpose  digital  computer  cap¬ 
able  of  interfacing  with  data  storage  peripherals. 

(p)  Be  capable  of  product  improvement  on  a  modular  basis. 

(q)  Provide  for  audio  alert  or  alarm,  indication  of  storage 
limit  overflow,  and  priority  message  alert. 

(r)  Provide  for  memory  expansion. 

(s)  Be  capable  of  handling  data  up  to  TOP  SECRET/SCI. 

(t)  Survive  in  a  nuclear  environment  as  long  as  crew  mem¬ 
bers  remain  capable  of  operating  it  (High  Altitude  Electromagnetic  Pulse 
(HAEMP)  is  required), 

(u)  Meet  operation,  storage,  and  transit  requirements  spec¬ 
ified  in  AR  70-38  (hot,  basic,  and  cold  categories) . ^ 

(v)  Comply  with  personnel  health  and  safety  standards. 

(w)  Comply  with  existing  DA  automation  security  reauire- 

ments. 


(x)  Provide  no  less  than  two  communications  ports  (but  be 
expandable  to  eight). 
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Department  of  the  Army,  Headquarters,  AR  70-38,  Research,  Development 
Test  and  Evaluation  of  Materiel  for  Extreme  Climatic  Conditions,  Washington, 
D.  C.,  1  August  1979  (UNCLASSIFIED). 


(y)  Accept  power  of  50  or  60  cycle;  110/120  and  220/240 


Volts  AC;  28  Volts  DC. 

(2)  After  reviewing  current  and  developmental  hardware  items  in 
light  of  the  minimum  essential  characteristics  and  the  CCS*  architecture, 
TRADOC  has  taken  the  following  positions: 

(a)  With  a  few  specific  exceptions,  the  TACCS  will  serve  as 
the  Army's  NDI  item  solution  for  the  CCS^  architecture. 

(b)  The  TCS,  TCT,  and  the  enhanced  SST  with  printer  will 
serve  in  those  locations  which  require  a  full  processor. 

(c)  All  emerging  battlefield  automated  systems  requiring  a 
terminal  or  workstation  must  consider  using  the  devices  above  to  meet  hardware 
requirements.  Nonuse  must  be  justified  to  and  approved  hy  the  ACCS  manager. 

6.  Hardware  Requirements  and  Allocations.  Using  the  Army  of  Excellence 
force  structure  and  the  CCS*  architecture,  CAC  recently  completed  a  study  of 
the  five  battlefield  functional  area  control  systems,  the  tactical  record 
traffic  system,  requirements  for  large  screen  display,  and  generic  processor 

3 

characteristics.  The  objective  of  the  study  was  to  identify  the  locations 
requiring  microprocessors  from  corps  through  battalion  and  separate  company. 

a.  As  a  result  of  the  study,  CAC  made  a  preliminary  allocation  of 
microprocessors  to  designated  staff  sections  within  the  type  of  units  included 
in  the  Army  of  Excellence  force  structure.  The  preliminary  allocations  were 
presented  to  TRADOC  centers  and  schools  for  proponent  comment  and  input. 
Allocations  to  engineer  units  were  critiqued  at  the  USAES  during  a 
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Department  of  the  Array,  US  Army  Training  and  Doctrine  Command,  US  Armv 
Combined  Arms  Combat  Development  Activity,  Battlefield  Communication  Review 
(BCR)  Terminal  Evaluation,  Fort  Leavenworth,  Kansas,  26  October  1983 

(■unclassified). 


CAC-sponsored  microprocessor  location  working  group  meeting  held  2ft  March 

1984.  After  all  proponent  comments  are  resolved,  a  memorandum  of  agreement 

will  be  developed  which  finalizes  the  requirements  and  locations  of  micro- 

2 

processors  and  related  devices  within  CCS  . 

b.  Proposed  allocations  to  engineers  and  others  are  shown  in  Figures 
A-7  through  A-16.  Figure  A-17  explains  the  abbreviations  and  symbols  used. 
The  BLD,  common  to  many  engineer  elements,  is  a  generic  hardware  item  that 
meets  the  minimum  characteristics  identified  in  paragraph  5b(l). 
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SEPARATE  HEAVY  BRIGADE  HQ-LEVEL  ALLOCATIONS 


SOURCE:  Working  Group  Read-ahead  Package 
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Figure  A-16 


ABBREVIATIONS  AND  SYMBOLS 


(') . Designates  Manuever  Control  System  NDI 

(*) . Replaced  when  ADACS  is  Fielded 

(**) . Replaced  when  ASAS  is  Fielded 

(***) . Replaced  when  CSS  Control  System  (TACCS  C2)  is  Fielded 

AC . .Access  Terminal 

ADACS . Air  Defense  Artillery  Control  System 

ASAS . All-Source  Analysis  System 

BLACS . Battalion-Level  Command  and  Control  System 

BLD . Battalion-Level  Device 

DAMMS . DA  Movement  Management  System 

FAX . Lightweight  Digital  Facsimile 

FDMD . . . Fire  Support  Team  Digital  Message  Device 

HPIP . Handheld  Personnel  Information  Processor 

LSD . Large  Screen  Display 

MCS . . . Maneuver  Control  System 

NDI. . . Non-Developmental  Item 

SAAS . Standard  Army  Ammunition  System 

SAMS... . Standard  Army  Maintenance  System 

SARSS . Standard  Army  Retail  Supply  System 

SHORAD  C2 . Short-Range  Air  Defense  Command  and  Control  System 

SSD . Small  Screen  Display 

SST . Single  Subscriber  Terminal 

TACCS . Tactical  Army  CSS  Computer  System 

TACFIRE . Tactical  Fire  Direction  System 

TAMM1S . Theater  Army  Medical  Management  Information  System 

TCS. . .Tactical  Computer  System 

TCT . Tactical  Computer  Terminal 

TRTS . Tactical  Record  Traffic  System 

DLLS . Unit-Level  Logistics  System 

VFMED . Variable  Format  Entry  Device 


Figure  A-I7 
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DRAFT  FUNCTIONAL  REQUIREMENT  SPECIFICATIONS 
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THE  AUTOMATED  COMBAT  ENGINEER  OPERATIONS  AND  PLANNING  SYSTEM 
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1.  Purpose.  This  annex  describes  Che  draft  functional  requirement 


specifications  for  ACEOPS.  The  description  emphasizes  its  countermobility 
aspects  and  follows  the  foraat  specified  in  Technical  Bulletin  (TB)  18-100,  as 
closely  as  possible.* 

2.  Scope.  The  specifications  are  limited  to  the  information,  data,  and 
reports  which  must  be  exchanged  between  systan  elements  considered  standard 
throughout  the  system.  They  call  for  local  computation,  analysis,  and  pro¬ 
cessing  capability,  but  do  not  define  local  needs.  In  general,  local  process¬ 
ing  will  be  nonstandard,  based  on  the  needs  of  each  particular  commander  and 
staff. 

3.  Existing  System  Description. 

a.  The  ABPS  is  now  used  for  obstacle  planning  by  USAREUR.  This 
system  was  installed  in  1974  at  V  and  VII  Corps  Corps  Support  Command  (C0SC0M) 
data  processing  units  (DPUs)  on  IBM  360/40  computers. 

b.  The  ABPS  is  basically  a  noninteractlve,  administrative,  bookkeep¬ 
ing  system  which  produces  a  variety  of  data  summaries  and  reports,  including 
the  engineer  resource  requirements  needed  to  implement  the  obstacle  plans  of 
forward-deployed  forces.  Countermobility  data  are  originated  on  coding  sheets 
at  the  engineer  squad  level  and  reported  through  the  chain  of  command  to  the 
corps  staff  engineer.  The  data  are  prepared  on  a  series  of  80-column  punch 
cards,  processed  and  evaluated  at  the  corps  level,  and  returned  to  the  squad 
level  for  incorporation  into  target  folders.  The  ABPS  can  catalog  all  targets 
in  support  of  General  Defense  Plans  (GDPs).  It  also  can  provide  summaries  by 
types  of  materiel  and  levels  of  command;  by  map  sheet,  obstacle  type,  obstacle 

^Department  of  the  Army,  Headquarters,  TB  18-100,  Life  Cycle  Management, 
Appendix  M,  Washington,  D.  C.,  15  August  1981  (UNCLASSIFIED). 
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time  sequencing,  and  geographic  location;  and  can  audit  by  munition  storage 
location.  ABPS  programs  are  UNCLASSIFIED,  but  input  cards  and  output  print¬ 
outs  are  SECRET.  Figure  B-l  shows  the  relationships  between  ABPS  programs  and 
printed  reports. 

c.  Since  the  ABPS  was  fielded,  it  has  been  plagued  with  problems 
stemming  from  undocumented  modifications  (different  in  each  corps)  and  person¬ 
nel  turnover;  the  full  set  of  original  COBOL-F  programs  cannot  be  executed. 
In  1982,  the  ABPS  was  audited  and  reviewed  by  the  US  Army  Computer  Systems 
Support  Group,  Europe,  which  is  currently  correcting  basic  ABPS  program 
deficiencies.  No  other  ABPS  improvements  or  enhancements  are  planned. 

d.  The  ABPS  is  executed  semiannually,  or  as  requested  by  corps  major 
subordinate  commands.  Because  of  security  requirements  and,  currently,  the 
high  probability  of  a  program  abort,  it  is  not  uncommon  for  the  corps  to  wait 
weeks  before  the  ABPS  is  successfully  executed  at  the  DPUs  and  printouts  are 
returned  to  the  corps  staff  engineer. 

e.  Current  initiatives  to  Improve  the  ABPS  will  only  place  the  sys¬ 
tem  back  into  operation  with  enhancements  to  its  pre-edit  and  change  option 
capability.  These  changes  should  Improve  the  chances  of  full  program  execu¬ 
tion;  however,  they  will  not  improve  input/output  turnaround. 

f.  The  ABPS  is  marginally  adequate  for  meeting  peacetime  counter- 
mobility  planning  needs  only;  it  has  no  anticipated  wartime  application.  It 
cannot  support  sensitivity  analysis  of  the  obstacle  plan  or  answer  "what  if" 
questions,  and  does  not  interface  with  any  other  existing  or  planned  automa¬ 
tion.  It  also  cannot  accommodate  current  AFCENT  initiatives  for  ADP  target 


list  rationalization 


RELATIONSHIPS  BETWEEN  PROGRAMS  AND  PRINTED  REPORTS 


Prograa 

Reaark 

Code 

Report 

Classi¬ 

fication 

Printed  Output 

BAR01 

«• 

Sequential  Target  List 

S* 

One  target  suaaary  per  page 

Card  Error  Suaaary 

s 

List  of  card  typos  known  to  bo  la 
orror 

RAROZ 

b. 

Target-Type  Stannaries 

Corpswide 

S 

One-page  suaaary 

By  Zona 

S 

One  suaaary  per  zone 

Preparing  Unit  Stnaarlas 

By  Unit 

S 

One  suaaary  par  unit 

Target  Recap 

s 

One-page  suaaary 

Minafiald  Recap 

s 

One-page  stannary 

Executing  Authority  Stnaarlas 

By  Unit 

s 

One  suaaary  per  unit 

Target  Recap 

s 

One-page  suaaary 

Minefield  Recap 

s 

One-page  suaaary 

Sector  Stnaarlas 

By  Unit 

s 

One  euaaary  par  unit 

Target  Recap 

s 

One-page  suaaary 

Minefield  Recap 

s 

One-page  nmmary 

CRBA  Number  Suaaary 

s 

One  suaaary  per  priority  class 

Tactical  Unit  Priority  Summaries 

s 

One  suaaary  par  priority  data 

BAR03 

b. 

Mapsheet  Summaries 

s 

Coordinates  and  target  nuaberi 

sorted  by  asp  sheet  and  preparing 
unit 


BARQ* 

b. 

Material  Requirements  Summaries 
Corpswide 

Preparing  Unit 

S 

s 

One-page  i turnery 

One  suaaary  per  unit 

BAR05 

Oe 

Materiel  Comparison  Stnaarlas 

Prepositioned  Stock  Point  (PSP) 
Reference  List 

s 

Location  and  coordinates 
PSP 

of  each 

PSP  Materiel  Audits 

s 

One  suaaary  per  PSP 

Coordinate  List 

s 

List  of  coordinates  for 
assigned  to  a  PSP 

targets 

REMARKS 

a.  The  "A,"  *>,*  and  "C*  cards  aust  be  sorted  by  target;  all  cards  for  a  single  target  are  grouped 
together. 

b.  This  progrea  aay  not  be  executed  until  prograa  BAR01  creates  one  of  two  data  storage  files. 


*Downgraded  to  CONFIDENTIAL,  when  separated  fro a  all  other  pages. 


Figure  B-l 


g.  The  block  diagram  in  Figure  B-2  shows  how  data  flows  through  each 
organizational  element  that  produces  input  and/or  receives  output  from  the 
ABPS.  There  are  no  systems  external  to  ABPS  that  produce  input  and/or 
currently  receive  output  from  it. 

4.  Required  System  Capabilities. 

a.  The  ACEOPS  will  be  more  responsive  and  useful  as  a  peacetime 
planning  tool  for  countermobility  operations  than  the  ABPS.  ACEOPS  will  be 
designed  for  interactive  operation  and  local  processing,  so  obstacle  data  can 
be  manipulated  and  analyzed  as  part  of  the  day-to-day  GDP  planning  process. 
Visual  methods  such  as  video  and  graphic  plots,  as  well  as  hardcopy  printouts, 
will  be  exploited. 

b.  ACEOPS  will  have  a  wartime  application.  It  will  allow  users  to 
assess  and  report  the  status  of  countermobility  operations  during  execution  In 
real  or  near-real  time,  keep  records  on  the  status  of  obstacle  execution,  and 
streamline  the  obstacle  reporting  process.  In  addition,  ACEOPS  will  automate 
essential  reports  and  enhance  combat  engineer  C^. 

c.  ACEOPS  will  consist  of  a  network  of  modules  capable  of  sharing 

information  at  the  corps,  division,  and  brigade  staff  engineer  level.  Each 
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echelon  will  be  able  to  interface  with  the  five  functional  systems  of  the  CCS 
concept:  maneuver,  control,  intelligence,  and  electronic  warfare,  fire  sup¬ 
port,  combat  service  support,  and  air  defense  artillery.  Figure  B-3  describes 
the  anticipated  ACEOPS  data  flow  during  peacetime  operation.  Figure  B-4 
describes  the  ACEOPS  wartime  data  flow. 

d.  The  basic  system,  module  characteristics,  and  module  functions  of 
the  ACEOPS  are  outlined  below. 
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ACEOPS  DATA  FLOW 
(Peacetime) 


ACEOPS  DATA  FLOW 
(Wartime) 


(1)  ACEOPS  system  characteristics. 

(a)  Module  network. 

_i_.  Has  modules  at  corps,  division,  and  brigade  staff 

engineer  elements. 

2_.  Can  interface  with  command  and  control  elements  at 
maneuver  brigade,  division,  and  corps. 

2..  Can  share  information  through  interface  and 
courier-trans portable  magnetic  data  files. 

(b)  Can  process  and  transmit  classified  information  up  to 
SECRET/NATO-SECRET. 

(c)  Can  Interface  over  2-  and  4-wire  circuits.  Army  multi¬ 
channel,  and  host-nation  commercial  communication  systems. 

(2)  ACEOPS  module  characteristics. 

(a)  Can  do  local  processing. 

(b)  Has  a  data  base  management  system  with  edit  capabil¬ 
ities. 

(c)  Can  display  terrain  via  video  maps  or  digitized 

terrain. 

(d)  Can  develop,  update,  and  transmit  graphics,  formatted 
and  free-text  electronic  mail,  and  overlay  information. 

(e)  Can  produce  hardcopy  via  printer  or  plotter. 

(3)  ACEOPS  module  functions. 

(a)  Can  produce  resource  accounting  and  status  reports, 
such  as  task  organizations  and  unit  locations  (overlay  and  table);  obstacle 
emplacements  (type,  location,  resource  requirements);  and  materiel  require¬ 
ments  (type,  quantity). 


(b)  Can  provide  higher,  lower,  or  adjacent  units  with 
reports  required  by  operational  direction  and  standard  operating  procedures 


(SOPs). 

(c)  Can  store,  maintain,  and  retrieve  data  such  as  terrain 
information,  route  reconnaissance,  engineer  situation  (overlay),  and  engineer 
briefing  (update). 

5.  Information  Processing  Capabilities. 

a.  Data  element  definitions  and  input/output  formats  given  in  this 
paragraph  should  be  standardized  among  the  ACEOPS  modules.  To  the  extent 
practical,  they  should  be  consistent  and  compatible  with  the  external  report¬ 
ing  and  data  transfer  requirements  of  CENTAG,  AFCENT,  and  the  German  Terri¬ 
torial  Southern  Command  (GTSC).  Applicable  guidance  is  given  in: 

(1)  Central  Region  (CR)  Directive  80-71-3. ^ 

(2)  CR  Directive  80-71-6. 3 

(3)  CR  Directive  80-50. 4 

(4)  V  and  VII  Corps  Field  SOPs. 

b.  At  a  minimum,  ACEOPS  should  provide  processing  support  for  the 
following  reports:  ENGREP,  ENGRSPOTREP,  RIVER  BRIDGE  REP,  BARREP-A  through  E, 
and  MISSREP.  Figures  B-5  and  B-6  show  the  information  flow  and  frequency  of 
these  reports.  (Paragraphs  7  through  11  describe  each  report,  including  input 


o 

North  Atlantic  Treaty  Organization,  Allied  Forces  Central  Europe,  Head¬ 
quarters,  CR  Directive  80-71-3,  Combat  Interoperability  Engineer  Information 
Flow,  Brunssum,  Netherlands,  7  October  1982  (NATO-UNCLASSIFIED). 

3North  Atlantic  Treaty  Organization,  Allied  Forces  Central  Europe, 
Headquarters,  CR  Directive  80-71-6,  Combat  Engineer  Interoperability  APP  for 
Barrier  Target  Lists,  Draft,  Brunssum,  Netherlands,  19  December  1983  ( NATO- 
CONFIDENTIAL). 

4North  Atlantic  Treaty  Organization,  Allied  Forces  Central  Europe,  Head¬ 
quarters,  CR  Directive  80-50,  Land  Reporting  System  (LANDREP),  Part  II, 
Brunssum,  Netherlands,  1  August  1982  (NATO-CONFIDENTIAL^ . 
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Standardization  of  Engineer  Reporting  Within  V  Corps,  Letter,  AETV-EN,  with  7  Inclosures 
Frankfurt,  Federal  Republic  of  Germany,  21  April  1983  (UNCLASSIFIED)  (hereafter  referrei 
to  as  V  Corps  standardization  letter). 


data  elements  and  output  formats.)  Processing  support  should  include  hands-on 
operation,  user-friendly  input/output,  and  the  ability  to  perform  sensitivity 
analyses. 

c.  ACEOPS  also  should  provide  local  programming  support.  Although 
specific  input/output  relationships  cannot  be  defined,  necessary  processing 
capabilities  would  include  a  spreadsheet  capability,  a  data  base  system,  and 
at  least  one  high-level  programming  language. 

6.  Constraints. 

a.  An  Interim  system  capability  should  be  fielded  at  least  by  FY  87. 

b.  Since  ACEOPS  is  a  high-priority,  high-payoff  effort,  its  develop- 
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ment  should  be  given  top  priority  consistent  with  the  CCS  concept  of  the 
AC2MP. 

c.  ACEOPS  must  be  able  to  operate  with  120/200-volt,  50/60  Hertz 
power  (commercially  or  tactically  generated). 

d.  ACEOPS  system  modules  must  be  able  to  set  up  or  tear  down  in 
fewer  than  20  minutes  and  require  no  more  than  two  people  to  carry. 

e.  Modules  must  be  able  to  operate  from  stationary  command  post 
vehicles  and  armored  personnel  carriers.  They  must  be  rigged  well  enough  to 
withstand  tactical  cross-country  relocation  under  battlefield  conditions  in 
such  vehicles. 

7.  Barrier  Report  (BARREP). 

a.  Purpose:  BARREP  transmits  the  status  of  individual  obstacles  and 
obstacle  systems  from  lower  to  higher  headquarters.  It  projects  upcoming 
engineer  work  effort  and  forecasts  when  a  given  obstacle  or  system  will  be 
complete.  The  report  is  specifically  designed  to  transmit  obstacle  data  as 
the  force  transitions  from  peace  to  war;  it  demands  considerable  information 


on  Che  status  of  preplanned  barrier  systems.  The  report  is  dynamic,  changing 
as  additional  obstacle  systems  are  developed. 

b.  Security  classification:  SECRET. 

c.  Category  and  precedence:  Category  1,  immediate. 

d.  Submitted  by:  units  installing  obstacle  system. 

e.  When  submitted:  to  brigade  engineer  as  status  of  a  given  obsta¬ 
cle  or  obstacle  system  changes  state;  from  brigade  engineer  to  division 
engineer  and  from  division  engineer  to  corps  engineer  every  6  hours  (0600, 
1200,  1800,  and  2359). 

f.  Content:  five  formats,  as  described  below. 

(1)  BARREP-A  is  the  basic  obstacle  status  feeder  report.  The 
squad  or  platoon  leader  uses  BARREP-A  to  transmit  current  information  on  a 
single  obstacle.  The  report  feeds  directly  into  BARREP-B  without  translation 
in  form  or  content.  It  has  five  lines  of  data  designed  for  voice  transmission 
(see  Figure  B-7). 

(2)  BARREP-B  is  maintained  by  the  brigade  engineer  and  is  kept 
current  as  the  obstacle's  status  changes.  It  reports  the  status  within  a 
given  subsystem.  (A  subsystem  is  defined  as  a  logical  grouping  of  individual 
obstacles  which  support  a  task  force  commander's  scheme  of  maneuver.)  Every  6 
hours,  the  brigade  engineer  sends  a  current  copy  of  BARREP-B  to  the  division 
engineer  for  each  of  the  subsystems  in  the  brigade  sector.  Figure  B-8  shows 
the  BARREP-B  format. 

(3)  BARREP-C,  maintained  by  the  division  engineer,  derives 
information  from  BARREP-B.  It  translates  the  specific  data  from  BARREP-B  into 
an  analysis  of  obstacle  completion  (by  obstacle  type)  for  each  of  the  subsys¬ 
tems.  It  also  groups  the  task-force  subsystems  into  larger  brigade  systems. 


Figure  B-7 


-Continued 


BARREP-C  is  sent  from  division  to  corps  every  6  hours.  Figure  B-9  shows  the 
BARREP-C  format. 

(4)  BARREP-D,  maintained  at  corps  level,  is  derived  from 
BARREP-C.  It  groups  subsystems  into  a  single  system,  providing  a  quick  refer¬ 
ence  status  check  of  obstacle  system  completion  across  the  corps.  It  is  the 
basis  for  reporting  to  higher  headquarters.  Figure  B-10  shows  the  BARREP-D 
format. 

(5)  BARREP-E,  maintained  at  brigade  engineer  level,  records  the 
status  of  enemy  obstacles  as  they  are  encountered  by  friendly  forces. 
Friendly  obstacles  that  were  previously  posted  to  BARREP-B  are  transferred  to 
BARREP-E  as  they  fall  into  enemy  hands.  BARREP-E  is  transmitted  to  the  divi¬ 
sion  engineer  every  6  hours.  Figure  B-ll  shows  the  BARREP-E  format. 

g.  Identifying  obstacles,  systems,  and  subsystems: 

(1)  Individual  obstacles  will  be  numbered  using  the  target  num¬ 
bers  assigned  by  the  Central  Region  Barrier  Agreement  (CRBA).  Obstacles 
emplaced  after  hostilities  begin,  and  which  are  not  numbered  as  part  of  the 
CRBA,  will  be  assigned  numbers  using  the  corps  system. 

(2)  Obstacle  subsystems  are  groups  of  individual  obstacles  which 
work  together  to  support  a  tactical  commander's  scheme  of  maneuver;  each  group 
is  determined  by  the  brigade  engineer.  A  subsystem  can  he  a  single  obstacle, 
a  linear  grouping  of  obstacles,  or  even  a  large  number  of  obstacles  spaced 
widely  apart.  The  brigade  engineer  can  number  each  subsystem  within  his 
brigade  sector  from  01  through  99.  The  division  engineer  will  assign  blocks 
of  numbers  to  each  brigade  engineer. 

(3)  Obstacle  systems  are  groups  of  obstacle  subsystems;  each 
group  is  determined  by  the  division  engineer.  A  system  can  be  composed  of  a 


BARREP-C* 


Name  or  PROJECTED 

em  Name  Z  Complete  DTP  COMPLETED 


BARREP-E* 


*SOURCE:  V  Corps  standardization  letter 


single  subsystem  or  many  subsystems.  The  division  engineer  identifies  each 


system  by  lettering  it  from  A  to  ZZ.  Each  system  is  distinguished  from 
adjacent  divisional  systems  by  placing  the  system  letter  after  the  division 
number. 

h.  Overlays:  Overlays  showing  obstacles,  subsystems,  or  systems  are 
maintained  at  all  levels.  With  appropriate  color-coding  and  accurate  posting, 
they  provide  up-to-date  status  information  for  command  briefings. 

8.  Engineer  Report  (ENGREP) . 

a.  Purpose:  ENGREP  is  the  platoon  leader’s,  company  commander’s, 
battalion  commander's,  brigade  engineer's,  or  division  engineer's  daily 
assessment  of  the  engineer  situation  in  his  area  of  responsibility.  It  high¬ 
lights  specific  engineer  issues  that  are  or  will  impact  on  the  battle  and 
critical  administrative  or  logistic  information  that  could  affect  the  opera¬ 
tional  capability  of  a  unit. 

b.  Security  classification:  SECRET. 

c.  Category  and  precedence:  Category  1,  priority  or  higher  (as 
required). 

d.  Submitted  by:  engineer  commanders. 

e.  When  submitted:  from  State  of  Military  Vigilance  (MV)  onwards. 

(1)  To  Army  group  by  0200Z  as  of  2359Z 

(2)  To  corps  by  2300Z  as  of  2359Z  (i.e.,  a  forecast  of  the 
situation  expected  at  2359Z). 

(3)  To  division  engineer,  engineer  brigade,  or  regimental 
engineer  by  2100Z  as  of  2359Z  (forecast). 

(4)  To  brigade  engineer  by  1900Z  as  of  2359Z  (forecast). 


f.  Distribution: 


(1)  Action — direct  higher  headquarters  (primary,  static  or  main) 
and  alternate  command  headquarters  (rear,  mobile,  or  tactical  command  post). 

(2)  Information — flanking  formations  or  units  and  other  head¬ 
quarters  (as  appropriate). 

g.  Content: 

(1)  Part  I — Assessment  of  the  Engineer  Situation.  Part  I  gives, 
in  free  text,  the  engineer  commander’s  assessment  for  the  past  or  next  24 
hours  of  engineer  activity.  It  may  include  any  of  the  following  items: 

(a)  A  review  of  the  tasks  completed  during  the  previous  24 


hours . 


(b)  Engineer  tasks  planned  for  the  next  24  hours. 

(c)  An  appraisal  of  the  unit's  personnel  strength  as  it 
relates  to  combat  effectiveness  (green  -  operational,  amber  ■  marginal,  red  ■ 
not  able  to  accomplish  mission). 

(d)  An  appraisal  of  the  unit's  equipment  status  as  it 
relates  to  combat  effectiveness  (green,  amber,  red). 

(e)  Availability  of  Class  I  stocks  (green  ■  adequate 
stocks;  amber  ■  shortages  of  some  provisions,  but  still  operational;  red  * 
shortage — not  sufficient  to  accomplish  the  mission). 

(f)  Availability  of  Class  III  stocks  (green,  amber,  red). 

(g)  Availability  of  Class  V  stocks  (green,  amber,  red). 

(h)  Mission-oriented  protective  posture  (MOPP)  level 

1  through  4. 


(i)  Radiation  level  (green,  amber,  red). 

( j )  Current  location  and  location  of  subordinate  units. 


(k)  Current  task  organization,  if  changed  since  last 

report. 

(l)  Present  or  foreseen  problems  or  shortages. 

(m)  A  statement  that  there  has  been  no  change  from  the 

previous  report. 

(n)  Additional  remarks  not  covered  hv  previous  comments  or 
a  statement  to  clarify  a  previous  comment. 

(2)  Part  II — Atomic  Demolition  Munitions  (ADM)  Site  Preparation 
Assets  and  Status.  Part  II  is  a  formatted  message  which  gives: 

(a)  Number  of  operational  ADM  military  construction  (MC) 

teams . 

(b)  Number  of  operational  military  drilling  rigs. 

(c)  Number  of  operational  civilian  drilling  rigs. 

(d)  Number  of  ADM  shafts  drilled  to  the  desired  depth  by 
GDP  option  area  and  reference  number  to  date  (chambers  drilled  in  overlapping 
GDP  option  areas  are  reported  only  once). 

(3)  Part  III — Equipment  Status.  Part  III  uses  DA  Form  2406  to 

report  equipment  status  through  the  brigade  engineer  to  the  division  engineer. 
At  division  level,  the  unit's  operational  capability  is  summarized  and  sent  to 
the  corps.  Although  the  corps  commander  does  not  need  a  "bumper  number" 

report  on  vehicle  status,  the  status  of  certain  critical  equipment  types  such 
as  5-ton  trucks,  dozers,  bucket  loaders,  and  tank  and  pump  units  must  be 

reported.  Figure  B-12  shows  the  Engineer  Equipment  Status  Summary  form. 

(4)  Part  IV — Engineer  Data  Sheet.  Part  IV  presents  critical 
information  on  the  status  of  mobility,  countermobility,  survivability,  and 
personnel  assets  (see  Figure  B-13).  It  can  be  expanded  to  include  any  item 
considered  critical  to  the  operational  capability  of  engineer  units. 


ENGINEER  EQUIPMENT  STATUS  SUMMARY* 


*SOUKCE:  V  Corps  standardization  letter. 

**0/H  =  On-hand  equipment;  FMC  =  Fully  mission  capable 


ENGINEER  DATA  SHEET* 


FROM: 


AS  OF: 


*SOURCE:  V  Corps  standardization  letter. 


Figure  B-13 


Engineer  Mi s sion  Coordination  Sheet  (MISSREP) 


a.  Purpose:  MISSREP  is  an  operational  report  which  establishes  a 
standard  format  for  coordinating  engineer  missions.  It  is  designed  to 
efficiently  transfer  specific  details  about  an  engineer  mission  between  opera¬ 
tional  levels. 

b.  Security  classification:  SECRET. 

c.  Category  and  precedence:  Category  1,  priority  or  higher  (as 
required) . 

d.  Submitted  by:  engineer  commanders  at  all  levels. 

e.  When  submitted:  as  required. 

f.  Submitted  to: 

(1)  Action — subordinate  headquarters  responsible  for  accomplish¬ 
ing  missions  and  higher  headquarters  as  required. 

(2)  Information — as  required. 

g.  Content:  Using  the  serial/line  number  system,  the  sender  need 
not  transmit  more  than  the  specific  details  of  each  mission.  Figure  B-14 
shows  the  MISSREP  format  and  mission  type  codes. 

10.  Engineer  Spot  Report  (ENGSPOTREP) . 

a.  Purpose:  ENGSPOTREP  provides  engineer  staffs  at  various  levels 
with  information  on  items  of  particular  engineer  operational  importance.  This 
is  the  only  engineer  report  that  tracks  the  actions  of  enemy  engineers. 

b.  Security  Classification:  usually  SECRET. 

c.  Category  and  precedence:  Category  1,  priority  or  hivher  (as 
required) . 


corps 


d.  Submitted  by:  engineer  commanders  at  brigade,  division,  and 

level  to  their  respective  superior  engineer  commanders  and  territorial 
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MISSREP  FORMAT  AND  MISSION  TYPE  CODE* 


commands  of  all  levels  to  the  appropriate  engineer  comraander(s )  in  their  area 
of  responsibility. 

e.  When  submitted:  as  required. 

f.  Submitted  to: 

(1)  Action — direct  higher  headquarters  (primary,  static,  or 

main). 

(2)  Information — appropriate  territorial  or  allied  commands,  and 
others  (when  applicable) 

g.  Content:  This  report  (in  free-text  format)  allows  engineer 
commanders  and  their  staffs  to  keep  their  superiors  fully  informed  of  events 
of  engineer  operational  importance;  it  also  transmits  information  from  higher 
to  lower  headquarters.  It  should  be  submitted  when  events  like  those  listed 
below  occur. 

(1)  Outloading  of  barrier  material  to  field  locations  begins. 

(2)  Personnel  and  barrier  material  arrive  at  Zone  A  target  loca¬ 
tions. 

(3)  Barrier  preparations  begin  in  Zone  A  in  each  corps  area 
after  the  appropriate  alert  measure  is  declared. 

(4)  Significant  delays  in  planned  barrier  preparations  occur. 

(5)  Significant  shortage  of  mines,  barrier  materials,  manpower, 
and  bridging  occur. 

(6)  Vital  targets  (as  listed  in  CRBA  Article  5,  paragraph  j)  are 

destroyed. 

(7)  Important  targets  specified  by  AFCENT  or  Army  groups  are 
destroyed  or  captured. 

(8)  Major  denial  measures  are  executed. 


(9)  Important  obstacles  fall  intact  into  enemy  hands. 

(10)  Barrier  material  is  lost. 

(11)  Engineer  ammunition  is  sabotaged. 

(12)  Engineer  ammunition  storage  sites  are  sabotaged. 

(13)  The  transfer  of  barrier  from  one  formation  to  another  begins 


or  ends. 


(14)  Am  teams  are  lost. 

(15)  Drilling  rigs  are  lost. 

(16)  Reinforcing  engineer  units  arrive. 

(17)  Engineers  are  used  in  a  nonengineer  role. 

(18)  Family  of  Scatterable  Mines  (FASCAM)  minefields  are  emplaced 
(report  Includes  start  point  coordinates,  length,  density,  and  effective 


duration). 


cated. 


(19)  Any  command  post  at  the  company  level  or  higher  is  relo¬ 


(20)  Any  contact  is  made  with  enemy  force  (report  includes  compo¬ 
sition  and  nature  of  contact). 

11.  River  Bridge  Report  (RIVER  BRIDGE  REP). 

a.  Purpose:  RIVER  BRIDGE  REP  is  an  operational  report  which  estab¬ 
lishes  a  standard  format  fo.  coordinating  tactical  river  or  raft  missions.  It 
is  designed  to  efficiently  transfer  specific  details  about  engineer  river 
bridge  missions  between  operational  levels. 

b.  Security  classification:  SECRET. 


c.  Category  and  precedence:  Category  1,  priority  or  higher  (if 


required). 


d.  Submitted  by:  engineer  commanders  at  all  levels. 
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e.  When  submitted:  as  required. 

f.  Submitted  to: 

(1)  Action — subordinate  headquarters  responsible  for  accomplish¬ 
ing  missions  and  higher  headquarters  (as  required)  to  Inform  the  unit  of  river 
bridge  status. 

(2)  Information — as  required. 

g.  Content:  Lines  1  through  5  of  the  report  are  transmitted  to  the 
corps  engineer  level;  lines  6  through  14  contain  more  specific  information  and 
are  not  reported  beyond  the  brigade  engineer  or  engineer  battalion  level.  The 
following  format  is  used  to  transmit  this  report: 

(1)  Line  1 — bridge/raft  type  code. 

(2)  Line  2 — location  of  crossing  site. 

(3)  Line  3 — time  required  to  be  operational. 

(4)  Line  4 — unit  operating  the  crossing  site. 

(5)  Line  5 — crossing  unit. 

(6)  Line  6 — DTG  first  vehicle  arrives  at  near-shore  engineer 
reporting  point  (ERP). 

(7)  Line  7 — DTG  last  vehicle  departs  at  near-shore  ERP. 

(8)  Line  8— number  of  vehicles  at  near-shore  ERP  (wheeled  or 

tracked). 

(9)  Line  9 — DTG  first  vehicle  arrives  at  the  crossing  site. 

(10)  Line  10 — DTG  last  vehicle  departs  the  crossing  site. 

(11)  Line  11 — number  of  vehicles  to  cross  (wheeled  or  tracked). 

(12)  Line  12 — DTG  first  vehicle  arrives  at  far-shore  ERP. 

(13)  Line  13— DTG  last  vehicle  departs  the  far-shore  ERP. 

(14)  Line  14 — number  of  vehicles  at  far-shore  ERP. 
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1.  Purpose.  This  annex  describes  the  various  combat  engineer  activities 
in  USAREUR  that  were  identified  as  candidates  for  automation  by  ESC's  ques¬ 
tionnaires  and  interviews,  and  by  ESC's  review  of  a  variety  of  documents  per¬ 
taining  to  engineer  plans  and  operations. 

2.  Limitations. 

a.  The  automation  applications  outlined  in  this  annex  do  not  exhaust 
all  possibilities,  and  generally  reflect  needs  based  on  the  current  methods  of 
operation.  Changes  in  doctrine,  threat,  operational  concepts,  force  struc¬ 
ture,  unit  design,  and  so  forth  are  certain  to  create  new  automation  needs  and 
change  or  eliminate  others. 

b.  The  candidates  for  automation  suggested  by  ESC's  research  sources 
may  have  been  constrained  by  the  perceived  capabilities  of  current  hardware 
and  software  systems.  Because  of  rapid  advances  in  automation  technology, 
these  identified  applications  could  be  short  lived.  For  that  reason,  auto¬ 
mation  needs  are  stated  generically  and  are  not  related  to  specific  hardware 
or  software  systems. 


C-l 


3.  Information  Systems.  These  kinds  of  applications  involve  the  trans¬ 
fer  of  technical,  staff,  and  command  information  among  the  various  organiza¬ 
tions  and  echelons.  Detailed  technical  and  staff  information  is  processed  and 
aggregated  in  varying  degrees  depending  on  which  echelon  in  the  force  organi¬ 
zation  is  generating  the  command  information.  The  information  is  event  and 
status  oriented,  and  is  amenable  to  reporting  systems  designed  to  update  data 
bases  previously  established  (often  using  preformatted  documents).  Automating 
these  processes  exploits  the  speed  and  accuracy  with  which  computers  manipu¬ 
late  large  data  bases,  efficiently  receive  and  transfer  formatted  data,  and 
generate  a  wide  variety  of  decision  aids.  Combat  engineer  information  systems 
candidates  include  the  following  applications: 

a.  Engineer  status  and  situation  assessment  reports.  Reports  in 
this  category  are  derived  from  CR  directives  and  corps  SOPs.  They  contain  the 
minimum  essential  information  needed  at  each  level  of  command.  Within 

USAREUR,  reports  in  this  category  constitute  the  basic  combat  engineer  auto- 

2 

■nation  requirements  underlying  the  engineer  subsystem  CCS  .  The  specifica¬ 
tions  in  Annex  B  are  derived  from  these  reports.  Specific  report  modules 
include: 

(1)  Engineer  Assessment,  Reporting  of  Site  Preparation  for  ADM, 
and  Reporting  of  Barrier  Preparation  (this  report  is  required  by  CR  Directive 
80-71-3).  Detailed  information  supporting  this  report  is  acquired  by  the 
USAREUR  corps  using  the  ENGREP,  BARREP,  Engineer  Situation  Report,  and 
ENGSPOTREP.  Detailed  data  are  aggregated  in  the  specified  document  format  at 
corps  level  for  submission  to  higher  headquarters. 

(2)  ENGSPOTREPs.  These  reports  are  required  at  all  levels  and 
contain  information  of  particular  operational  importance  to  the  engineer 
commanders  at  each  level. 
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(3)  Engineer  resource  data.  This  report  is  designed  to  provide 
engineer  staffs  at  various  levels  of  command  with  basic  planning  data.  The 
basic  engineer  data  sheet  is  established  in  peacetime  and  is  designed  to  be 
updated  during  periods  of  tension  and  after  hostilities  begin  by  using  the 
engineer  data  report.  The  ENGREP  proposed  in  Annex  B  is  designed  to  fulfill 
this  reporting  requirement. 

b.  Minefield  reports.  These  reports,  required  by  Standardization 
Agreement  (STANAG)  2036  and  directed  by  the  CR,  are  included  in  USAREUR  corps 
SOPs.  Normally,  minefield  reports  are  not  submitted  above  corps  level.  The 
reports  encompass  conventional  and  scatterable  minefields.  They  require  both 
textual  information  and  graphical  representations  such  as  scaled  overlays  and 
sketches.  Basic  minefield  report  data  are  provided  by  the  BARREP,  ENGSPOTREP, 
Mission  Coordination  Sheet,  and  ENGREP. 

c.  Transfer  of  obstacle  documentation.  After  the  start  of  hostili¬ 
ties,  there  is  a  need  to  provide  timely,  comprehensive,  and  accurate  data  on 
the  status  and  location  of  obstacles  to  engineer  and  operational  staffs  of 
flanking  units,  replacement  units,  and  units  affected  by  sector  boundary 
changes.  The  information  to  be  transferred  requires  that  scaled  overlays  and 
standard  obstacle  documentation  (specified  by  CR  directive)  be  exchanged. 

A.  Data  Bases  and  Analyses.  Combat  engineer  commanders  and  staffs  need 
to  produce  plans,  provide  technical  input  to  others,  and  make  decisions  in 
both  peacetime  and  wartime.  These  activities  require  the  accumulation  and 
analysis  of  large  amounts  of  data  which  may  change  frequently.  Automation  has 
the  potential  to  improve  the  speed,  accuracy,  and  efficiency  with  which  engi¬ 
neers  perform  these  tasks.  Applications  in  this  area  are  of  two  broad 
types:  data  bases  and  analysis  procedures. 


a.  Data  bases.  These  kinds  of  applications  include:  establishing 
and  maintaining  data  bases,  data  manipulating  procedures,  and  the  output  of 
required  information  in  useful  forms  such  as  visual  displays  and  formatted 
text. 

(1)  Engineer  reconnaissance  and  intelligence  data.  This  data 
base  can  be  established  in  peacetime  and  updated  as  needed  during  peacetime  or 
wartime.  The  data  base  would  include  data  pertaining  to  terrain,  routes  and 
bridges,  river-crossing  sites,  obstacles  and  minefields,  denial  operations, 
and  engineer  equipment,  facilities,  and  materials.  The  data  base  system 
should  provide  for  the  graphic  display  of  areas  of  interest  (e.g. ,  video  maps 
with  topical  overlays)  as  well  as  formatted  reports  and  other  decision  aids. 

(2)  Engineer  material  stocks,  location,  and  status.  This  data 
base  should  include  US  Army  engineer  Class  IV,  Class  V,  bridging,  and  other 
key  material  items  as  well  as  host-nation  engineer  material  items  which  US 
forces  could  have  access  to  in  wartime. 

(3)  Organizational  information.  These  data  bases  are  intended 
to  facilitate  the  day-to-day  administration  of  engineer  organizations  at  all 
levels.  The  types  of  information  included  pertain  to  training  activities, 
rosters,  Table  of  Organization  and  Equipment  (TOE)  data,  task  organization, 
schedules,  and  similar  items. 

b.  Analysis  procedures.  Applications  in  this  category  utilize  the 
capability  of  the  computer  to  perform  calculations  and  complex  analyses. 
Automation  permits  a  more  complete  and  comprehensive  evaluation  of  alter¬ 
natives  ("what  if"  type  analyses)  and  increises  staff  productivity  and 
responsiveness.  The  procedures  can  rely  on  standard  computer  software  to  some 
extent,  but  most  will  require  system  programming  support.  Typical  analytic 
applications  include: 


(1)  Scheduling  and  allocating  the  engineer  material  movement  of 
haul  resources  consistent  with  the  priority  of  material  needs  and  quantities 
required. 

(2)  Determining  the  impact  of  changes  in  mission  priorities  on 
engineer  resource  allocations,  task  organization,  etc. 

(3)  Analyzing  the  effects  of  changes  in  available  engineer 
resources  (units  and  material)  on  assigned  missions,  plans,  tasks,  priorities, 
task  organization,  etc. 

(4)  Assessing  the  impact  of  changes  in  plans  (i.e.,  changes  in 
the  obstacle  plan)  on  resource  allocations,  material  stocks  required  and  their 
distribution,  task  organization,  priorities,  etc. 

(5)  Evaluating  material  stockage  posture  (e.g. ,  best  stock  dis¬ 
tribution  plan  and  alternative  or  better  stock  point  locations). 

(6)  Calculating  detailed  resource  requirements  for  individual 
tasks  such  as  craters,  minefields,  bridge  demolitions,  river-crossing  opera¬ 
tions,  emplacement  construction,  and  the  many  other  engineer  tasks. 

5.  Miscellaneous  Applications.  These  kinds  of  applications  can  best  be 
described  as  office  automation  requirements  generated  more  by  current  peace¬ 
time  needs  than  wartime  requirements.  However,  once  the  hardware  is  in  place, 
the  capability  exists  to  perform  the  applications  in  wartime.  Typical  appli¬ 
cations  in  this  category  include: 

a.  Preparation  of  administrative  correspondence  (i.e.,  word  process¬ 
ing). 

b.  Preparation  of  plans,  operations  orders,  reports,  and  other  for¬ 
matted  documents. 


c.  Electronic  mail 


d.  Maintenance  of  organizational  administrative  files  such  as  ros¬ 
ters,  calendars,  distribution  lists,  addresses,  phone  numbers,  inventory 
lists,  library  holding  lists,  and  personnel  data  (e.g.,  weapons  qualifica¬ 
tions,  driver's  licenses). 
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I.  INTRODUCTION 

1.  Purpose.  At  the  completion  of  this  study,  ESC  published  a  draft 
report  that  was  distributed  for  review  and  comment  to  the  study  sponsor,  the 
Study  Advisory  Group,  and  a  select  list  of  agencies  Interested  in  the  study 
topic.  The  purpose  of  this  annex  Is  to  present  the  results  of  that  review 
process. 

2.  Scope.  This  annex  presents  ESC's  response  (Section  II)  to  the 
significant  and  substantive  comments  received  on  the  draft  report  (Sections 
III,  IV  and  V).  (No  editorial  comments  are  included  since  they  were  auto¬ 
matically  Included  In  the  final  report,  either  in  response  to  review  comments 
or  as  part  of  ESC's  routine  editorial  process.)  In  addition,  concurrences 
were  telephoned  to  ESC  by  three  agencies: 

a.  HQ  Combined  Arms  Center  (ATZL-CAC-CD) ,  Fort  Leavenworth,  Kansas 


b.  HQDA  DCSOPS  Command,  Control,  Communications,  and  Computers 
Directorate  (DAM0-C4),  Washington,  D.  C.  20301. 

c.  DARCOM  Center  for  System  Engineering  and  Integration  (CENSEI), 
Fort  Monmouth,  New  Jersey. 


/  /  f  «*. 


II.  DISPOSITION  OF  COMMENTS 


3.  Actions  on  USAREUR  DCSENGR  Comments  (see  Section  III).  ESC  inter¬ 
prets  the  comments  from  USAREUR  DCSENGR  (see  Section  III)  as  a  concurrence 
with  the  study  report.  No  action  is  required  on  paragraphs  I,  2,  3,  and  6  of 
their  response.  ESC's  positions  or  actions  on  the  remaining  comments,  keyed 
to  paragraphs  in  the  USAREUR  response,  are  as  follows: 

a.  Paragraph  4a:  Agree.  TEMPEST  secure  operation  is  intrinsic  to 
the  capability  stated  in  Annex  B,  paragraph  4d(l)(b)  and  Annex  A,  paragraph 
5b(l)(s)  and  (u).  Capabilities  to  operate  in  a  field  environment  are  ade¬ 
quately  covered  in  Annex  A,  paragraph  5b(b),  (j),  (k),  (m),  (n),  (t),  and  (u). 

b.  Paragraph  4b:  The  system  development  process  requires  testing 
before  acceptance  and  fielding.  ESC  believes  that  it  is  premature  to  specify 
the  manner  or  vehicle  for  testing  at  this  time. 

c.  Paragraph  4c:  Agree. 

d.  Paragraph  4d:  The  study  recommendations  can  be  implemented 

immediately,  and  that  is  what  ESC  proposes.  The  wording  of  the 
recommendations  has  been  modified  to  reflect  this  position.  However,  the 
nature  of  the  comments  hints  that  a  system  development  milestone  schedule  is 
what  is  desired.  System  development  is  beyond  the  scope  of  the  study. 

e.  Paragraph  5:  Agree.  Recommendations  have  been  modified  accord¬ 
ingly. 

4.  Actions  on  USAES  Comments.  ESC  interprets  the  USAES  comments  (see 
Section  IV)  as  general  concurrence.  ESC’s  position  on  paragraph  2  of  the 
USAES  response  is: 

a.  The  study  was  done  for  USAREUR  DCSENGR  and  it  follows  that  it 
relies  primarily  on  USAREUR  engineer  community  perceptions  of  needed 


manage!  ent  information  and  tools.  ESC  believes  that  linking  ACEOPS  to  CCS^ 
2 

and  AC  MP,  as  recommended,  would  result  in  an  engineer  system  as  universally 

2  2 

applicable  as  any  other  functional  system  in  CCS  or  AC  MP.  Modification  or 

expansion  to  include  other  world  areas,  if  needed  at  all,  could  be  included  in 
2  2 

the  orderly  CCS  and  AC  MP  implementation  process. 

b.  ESC  agrees  that  CERL  is  fully  capable  of  ACEOPS  software 
development  and,  if  adequately  funded,  could  produce  in  a  manner  compatible 
with  CCS^  and  AC^MP.  A  recommendation  has  been  added  reflecting  this 
position. 

5.  Actions  on  CERL  Comments.  After  receiving  CERL's  comments  (see 
Section  V),  ESC's  ACEOPS  team  contacted  CERL  to  discuss  the  comments  In  more 
detail,  particularly  the  nature  and  merits  of  CERL's  research  and  development 
proposal  for  Combat  Engineer  Command  and  Control  Systems.  As  a  result  of 
these  discussions,  ESC  believes  that  what  CERL  proposes  is  feasible  and 
includes  the  concepts  and  capabilities  called  for  in  ACEOPS.  The  principal 
constraint  will  be  funding  to  support  the  level  required  for  timely 
development. 


LAST  PAGE  OF  ANNEX  D 
D-4 


/.vj.'.v.v: 


■r.  •' 


iVV.VA  .S 


DEPARTMENT  OF  THE  ARMY  Mason/tpm/AUTOVON 

HEADQUARTERS.  UNITED  STATES  ARMY,  EUROPE,  and  SiVCKTK  ARMY  370-8011 

omci  Of  THE  DCfUTY  CHIEF  OF  STAFF,  INOINfIR  ' 

AfO  NEW  YORK  09403 

13  SEP  1984 


AEAEH-MET 

SUBJECT:  Draft  Study:  Automated  Combat  Engineer  Operations  and  Planning 
System  (ACEOPS) 


Commander /Director 

US  Army  Engineer  Studies  Center 

Casey  Building  #2594 

Fort  Belvoir,  Virginia  22060-5583 


1.  Reference  draft  study  done  by  Engineer  Studies  Center  (ESC),  entitled 
Automated  Combat  Engineer  Operations  and  Planning  System  (ACEOPS),  dated  May 
1984. 

2.  This  office  has  reviewed  subject  document  and  requested  comments  from 
appropriate  subordinate  commands.  Response  has  been  limited,  however  some 
comments  are  furnished  for  your  consideration  prior  to  final  publication  of 
the  study. 

3.  ACEOPS,  as  conceived,  offers  a  much  needed,  and  long  overdue,  facility  for 
the  accumulation,  processing,  and  transmitting  of  essential  engineer 
information.  Current  automatic  data  processing  capability  for  engineers  in 
this  theater  is  limited  to  the  Automated  Barrier  Planning  System  (ABPS), 
accurately  described  in  the  study  as  barely  adequate.  ACEOPS  represents  a 
dynamic  capability  to  interactively  process  needed  data  in  a  timely  and  useful 
manner.  The  stipulation  that  it  be  completely  interfaced  with  the  rest  of  the 
ADP  programs  projected  for  the  corps  level  is  one  of  overriding  importance. 

4.  Additional  comments  include: 

a.  The  system  must  be  TEMPEST  secure  and  fully  capable  of  operation  (as 
well  as  mobility)  in  a  field  environment. 

b.  A  prototype  of  the  system  should  be  field  tested  at  a  major 
unclassified  exercise  (such  as  L0GEX)  prior  to  its  implementation. 

c.  The  draft  study  presents  a  good  overview  of  engineer  requirements,  for 
both  peace  and  war,  which  should  be  considered  in  the  development  of  the 
system. 

d.  A  proposed  milestone  plan  for  actual  implementation  of  the  study's 
recommendations  would  be  useful  to  planners  in  the  field. 


.  AEAEN-MET 

SUBJECT:  Draft  Study:  Automated  Combat  Engineer  Operations  and  Planning 
System  (ACEOPS) 

5.  As  indicated  frequently  in  the  draft,  engineer  input  to  the  Army-wide  plans  and 
concepts  for  automation  is  necessary.  Although  USAES  is  the  proponent  for  the 
provision  of  this  input,  this  headquarters  feels  it  to  be  critically  necessary  that 
it,  along  with  appropriate  corps  representation,  be  deeply  involved  as  the  ACEOPS 
concept  is  developed.  Study  recommendation  to  that  effect  could  lay  the  framework 
for  a  viable  cooperative  effort. 

6.  The  amount  of  work  and  research  devoted  to  the  preparation  of  this  draft  report 
is  both  obvious  and  appreciated.  We  look  forward  to  the  completion  of  the  final 
report  and  the  development  of  this  concept  as  a  working  tool  for  the  engineer, 
particulary  in  the  European  theater  of  operations. 

FOR  THE  DEPUTY  CHIEF  OF  STAFF,  ENGINEER: 


CECIL  0.  LOCKLEAR 
LTC,  GS 

Chief,  MET  Division 
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ATZA-CDC  (15  Apr  84)  1st  Ind 

SUBJECT:  Transmittal  of  the  Engineer  Studies  Center  Report,  "Automated  Combat 
Engineer  Operations  and  Planning  Systems  (ACEOPS).” 

US  Army  Engineer  School,  Fort  Belvoir,  Virginia  22060  ^  ®  1984 

TO:  Commander/Director,  Engineer  Studies  Center,  Corps  of  Engineer,  Casey 
Building  2594,  ATTN:  ESC,  Fort  Belvoir,  Virginia  22060 

1.  The  US  Army  Engineer  School  Directorate  of  Combat  Developments  has 
reviewed  the  subject  study  study.  It  is  an  excellent  attempt  to  present  the 
requirements  of  US  Army  Europe  combat  engineers  for  command  and  control 
automated  data  elements. 


2.  Recommend  that  consideration  be  given  to  expanding  the  study  to  include 
the  other  geopolitical  areas  of  the  world  where  US  Army  Engineers  would 
possibly  deploy  and  to  identify  specific  engineer  functions.  The  objective 
must  be  to  provide  a  viable  management  tool  and  no^'a> means  of  digitizing 
■Mini  reports.  The  system,  both  hardware  and  software,  must  be  totally 
compatible  with  the  Army  C^  system.  The  Construction  Engineering  Research 
Laboratory  could  generate  required  software. 

5.  The  USAES  POC  is  Mr.  Richard  Thompson,  ATZA-CDC,  AV  354-3504,  Com  664-3777. 
FOR  THE  COMMANDANT: 


wd  all  end 


’THEODORE  VANDER  ELS 
Colonel,  CE 

Director  of  Combat  Developments 
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DEPARTMENT  OF  THE  ARMY 

CONSTRUCTION  ENGINEERING  RESEARCH  LABORATORY.  CORPS  OF  ENGINEERS 

P.O.  BOX  4005 

CHAMPAIGN.  ILLINOIS  61820^305 

1  5  AUG  1984 

REPLY  TO 
ATTENTION  OF: 

CERL-FS 

SUBJECT:  Engineer  Studies  Center  Report,  "Automated  Combat 

Engineer  Operations  and  Planning  Systems  (ACEOPS)" 


Commander  and  Director 

Engineer  Studies  Center,  Corps  of  Engineers 
Casey  Building  2594 
Fort  Belvoir,  VA  22060 


1.  Ue  concur  with  the  findings  of  subject  study.  As  a  result  of  our 
work  in  a  related  area  this  year,  we  have  reached  the  same  conclusions 
as  In  your  report,  l.e.,  that  "engineer  automation  requirements  can  and 
should  be  included  for  concurrent  development  (with  the  maneuver  control 
system)"  and  that  an  Automated  Combat  Engineer  Operations  and  Planning 
System  (ACEOPS)  would  be  "expected  to  be  a  maneuver  control  subsystem." 
Ue  also  agree  that  the  strategy  should  be  to  use  hardware  that  is 
already  being  developed  In  support  of  Army-wide  Command  and  Control 
Subordinate  Systems. 

2.  What  you  have  named  ACEOPS  we  have  named  Combat  Engineer  Command  and 
Control  System  (CECCS).  USAES  has  asked  USA-CERL  for  assistance  in 
developing  a  CECCS.  While  the  work  will  not  begin  officially  until 
FY85,  we  have  done  some  preliminary  "philosophical  design"  thinking 
about  the  problem  in  an  attempt  to  bring  all  of  the  combat  engineer 
related  automation  initiatives  and  requirements  into  perspective.  In 
the  near  term,  we.  see  the  development  of  three  separate  "classes  of 
applications"  being  the  reality  -  CECCS  related  applications, 
topographic  related  applications,  and  technical  support  type 
applications.  Realistically,  these  three  type  applications  are  not 
going  to  merge  Into  an  integrated  systere(s)  until  well  into  the  future. 
At  Inclosure  1  are  some  concept  papers  that  we  have  developed  recently 
that  show  how  these  three  type  systems  might  relate  in  the  near  future 
and  In  the  2010  time  frame.  We  hope  they  are  food  for  thought. 


CERL-FS 

SUBJECT:  Engineer  Studies  Center  Report,  "Automated  Combat 
Engineer  Operations  and  Planning  System  (ACEOPS)" 

3.  You  should  be  aware  of  the  Computer  Based  Instruction  (CBI) 
Initiative  being  managed  by  Major  Rose,  chief  of  the  Captains  Training 
Team  (ATZA-TD-CTT)  at  USAES.  By  FY87  they  plan  to  start  putting  PLATO 
or  PLATO-like  terminals  in  every  combat  engineer  battalion  in  active  and 
reserve  units.  This  may  change  of  course,  depending  on  how  successful 
Phase  I  of  the  CBI  experiment,  the  school-house  phase.  Is.  But  It  shows 
that  there  are  major  peacetime  systems  also  being  developed  and,  since 
training  does  not  stop  In  wartime,  It  is  logical  to  assume,  that  In  the 
future  such  peacetime  systems  will  be  co-located  on  the  same  hardware 
used  In  the  combat  units  to  run  the  wartime  systems.  Thus,  the  system 
boundaries  get  fuzzier,  the  further  downstream  one  looks  In  time. 

4.  Reference  our  work  next  year  on  CECCS,  we  will  be  using  a  top-down 
approach  -  the  "Combat  Engineer  Command  and  Control  System”  work  unit  - 
In  conjunction  with  a  bottom-up  approach  to  the  problem  -  the  "Combat 
Engineer  Military  Computer  Applications”  work  unit.  This  Is  In  line 
with  the  "Evolutionary  Development"  approach  to  computer  systems 
development  espoused  by  CACDA.  Evolutionary  development  is  defined  as 
being  the  phased  development  and  early  fielding  of  system  sub- 
capabilities  according  to  a  prioritized  plan,  with  the  ultimate 
objective  of  satisfying  a  set  of  known  fixed  requirements  In  addition  to 
the  continuing  specification  of  additional  requirements  during  system 
development.  Information  on  these  two  work  units  and  other  USA-CERL 
work  units  addressing  automated  products  Is  at  Inclosure  2. 

5.  If  you  have  further  questions  on  our  views  or  on  the  work  we  will  be 
doing  In  this  area,  please  don't  hesitate  to  contact  either  Mr.  John 
Deponai,  Team  Leader,  Military  Engineering  Team,  FTS  958-7271,  or  Mr. 
Charles  Herring,  Principal  Investigator  for  the  Military  Computer 


Commander 

USAES 

ATTN:  ATZA-CDM/CPT  Khawaja 
Ft.  Belvolr,  VA  22060 
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